hello,
I'm working on porting the icst-ambisonics externals to PD and i have a couple of questions concerning the dsp-structure of externals in PD.
1) I'm currently experiencing what i think is reuse of signal vectors in the dsp-chain. it looks like input-vectors get overwritten with the output-vector before I'm done with my multichannel processing. in MSP there's a flag to prevent this. it's part of the x->pxobject the x-
x_obj.z_misc = Z_NO_INPLACE; flag. is there something equivalent in
PD? from the MSP docs: "If you set this bit in z_misc, the compiler will guarantee that all the signal vectors passed to your object will be unique. It is common that one or more of the output vectors your object will use in its perform method will be the same as one or more of its input vectors. Some objects are unable to handle this restriction; typically, this occurs when an object has pairs of inputs and outputs and writes an entire output on the basis of a single input before moving on to another input-output pair."
2) what i could glean from the docs/pdf's there is no way a signal inlet could be used for message-input at the same time, is that correct or is there a hack to get this work? i specifically need the left-most inlet to set the objects state etc. what the standard way of dealing with this in PD?
I'm grateful for any hints or ideas
/*j
/*j wrote:
hello,
I'm currently experiencing what i think is reuse of signal vectors in the dsp-chain. it looks like input-vectors get overwritten with the output-vector before I'm done with my multichannel processing. in MSP there's a flag to prevent this. it's part of the x->pxobject the x-
x_obj.z_misc = Z_NO_INPLACE; flag. is there something equivalent in PD?
from the MSP docs: "If you set this bit in z_misc, the compiler will
even though msp is a port of pd, pd is not msp. there is no such flag in pd, you have to take care of not overwriting the input signal yourself.
what i could glean from the docs/pdf's there is no way a signal inlet could be used for message-input at the same time, is that correct or is there a hack to get this work? i specifically need the left-most inlet to set the objects state etc. what the standard way of dealing with this in PD?
i don't know which docs/pdf's you are exactly reading, but pd has no problem with the first (leftmost) inlet accepting both signals and messages. there are plenty of externals that do that. have a look at [fiddle~] or [bonk~].
,fg-asd-r IOhannes
On Mon, 2006-04-03 at 12:20 +0200, IOhannes m zmoelnig wrote:
I'm currently experiencing what i think is reuse of signal vectors
in
the dsp-chain. it looks like input-vectors get overwritten with the output-vector before I'm done with my multichannel processing. in
MSP
there's a flag to prevent this. it's part of the x->pxobject the x-
x_obj.z_misc = Z_NO_INPLACE; flag. is there something equivalent in
PD?
from the MSP docs: "If you set this bit in z_misc, the compiler
will
even though msp is a port of pd, pd is not msp. there is no such flag in pd, you have to take care of not overwriting the input signal yourself.
well, there is always flext, which can be used as compatibility layer ..
t
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww! Jack Kerouac
even though msp is a port of pd, pd is not msp. there is no such flag in pd, you have to take care of not overwriting the input signal yourself.
well, there is always flext, which can be used as compatibility layer ..
True, but this doesn't save you from paying attention to input-output-aliasing. greetings, Thomas