hi all,
I have just started coding a multiple-instance-abstraction-embedder class (better known as poly~ in msp world). The question is: am I to a) do it in a simple way, which would suit all my current needs, or b) take into account a more general public, and _try_ do it well (no promises)?
Krzysztof
Where a) means using only remote interface (no in(~)/out(~)s), and banning nested abstractions.
am 09.02.2002 17:44 Uhr schrieb Krzysztof Czaja unter czaja@chopin.edu.pl:
hi all,
I have just started coding a multiple-instance-abstraction-embedder class (better known as poly~ in msp world). The question is: am I to a) do it in a simple way, which would suit all my current needs, or b) take into account a more general public, and _try_ do it well (no promises)?
Krzysztof
Where a) means using only remote interface (no in(~)/out(~)s), and banning nested abstractions.
Hi Krzysztof, for me, the poly~ object in Max is one of its main advantages over pd (apart from the better user interface) - so i would really be enthusiastic about a comparable mechanism here. I don't know too much about the internals of pd, but as i heard, in Max the advantage of the in~/out~- over to the send~/receive~-approach is, that it doesn't introduce the 1 signal vector delay then. I guess this delay also occurs in pd, so, in this sense, i would rather back the in~/out~-approach.
greetings, Thomas
hi with send~/receive~ the delay of one signalblock only appears if you have recursive loops, where the receive~ object is in the line of dsp-computing at an earlier point as the send~ object otherwise the signal is received without delay. (as far as i remember the pd-manual) marius.
I don't know too much about the internals of pd, but as i heard, in Max
the
advantage of the in~/out~- over to the send~/receive~-approach is, that it doesn't introduce the 1 signal vector delay then. I guess this delay also occurs in pd, so, in this sense, i would rather back the
in~/out~-approach.
greetings, Thomas
-
Krzysztof Czaja -
marius schebella -
Thomas Grill