Re: safe addition of arguments to existing ugens

On 2018-03-23 15:13, [email protected] wrote:
> i guess the array should always already be allocated with the known 
> size
> of the linked ugen, and when the synthdef requests fewer slots, as
> nathan writes, it will have to fill the uninitalised slots with a
> sensible default value (or if that's not possible at least gracefully
> terminate the ugen initialisation).

hi hanns,

right now, in our plugins system, we don't have a programmatic way of 
determining the actual number of inputs/outputs that a ugen wants. this 
is where a ugen metadata system would be a huge help.

but it gets muddy -- a good number of ugens have dynamic numbers of 
inputs or outputs that depend on their inputs. for example, PlayBuf has 
a dynamic output count based on the numChannels parameter, and SendReply 
has a dynamic input count due to a hacky way of passing in a string as a 
ugen input.* so it's a chicken-egg problem: in some special cases, we 
can't actually know the number of inputs to allocate until we've already 
read some of the inputs.

how to get around this and solve this the "right" way, i don't have a 
clear idea. however, within individual ugens, there is an immediately 
usable bandage. suppose MyUnit has inputs "bufnum" and "brightness", and 
we add a new input called "analogness." we just run a check for 
numInputs() and supply a default argument if it seems wrong:

class MyUnit : public SCUnit {
public:
     MyUnit() {
         m_bufnum = in0(0);
         m_brightness = in0(1);
         if (numInputs() > 2) {
             m_analogness = in0(2);
         } else {
             m_analogness = 0.5f;
         }
     }
}

i am having trouble imagining downsides to this. i am slightly worried 
about efficiency, since if we want to read the "analogness" argument 
continuously, we would probably need to run this same if statement in 
the calculation function.


nathan

*something that's been on my mind recently: wouldn't it be awesome if 
scsynth graphs had a full-on type system rather than trying to encode 
everything with floating-point signals? immediate consequence would be 
that our entire FFT system could be much, much less of a hack, and we 
could add support for high-precision signals (which was causing us grief 
with BufRd). unfortunately this seems VERY complicated to implement and 
would basically entail a complete overhaul of scsynth...

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/