[RTcmix-discuss] memory allocation proposal

[John Gibson]

There is no default value for maketable (or makeLFO or makerandom).
I think it would be confusing to introduce one in those cases.  The
default value makes sense as a value to use before the inst receives
any real-time data, as for MIDI, when there's no way to know what the
current state of a controller is before the user changes it.

Also, how does the instrument know what the default value was?
That information is something the PField handles privately, and
it really shouldn't be communicated to the inst, IMHO.

I think we should try the realloc idea. I would suggest that if the
initial value is an audio-rate value, that we use a max delay amount
that corresponds to the lowest audio-rate frequency.  In other words,
if someone asks for a comb pitch >= 20 Hz or a delay time <= .05 sec
(which is the same thing), then we should use .05 sec as the max
delay time. At 44100, that's < 9kB per channel.

That's based on the hunch that the vast majority of cases will be
either audio-rate or sub-audio-rate, rather than moving from one
to the other.

Hope I'm making sense.

JG


On Jan 10, 2005, at 3:21 PM, Brad Garton wrote:

> Hey gang --
>
> How about this for doing the allocation for 
> COMBIT/DELAY/PANECHO/whatever:
>
> Allocate based on the freq/delay p-field, using the default value set 
> up
> in maketable or makeconnection (whatever it is that gets passed in
> during init() by these instruments, or maybe I'm misunderstanding how 
> they
> work).  This would then work with no necessary realloc in these 
> situations:
>
> --  The p-field is a constant, then we get the optimum allocation.
> --  The default p-field value is the maxmimum amount we will need to 
> use 
> if it is being controlled by an external slider or table (again we get 
> the
> optimum alloction).
>
> But it wouldn't work (as John pointed out) if we wanted the initial
> default value to be something different than the maximum delay value.  
> In
> that case we kick into Doug's realloc-on-the-fly scheme.  This also has
> the advantage of not setting an arbitrary maximum on the length of the
> delays (can't wait to fire up my 24-hour PANECHO! :-)).
>
> brad