leonard

hi, sorry if this sounds obvious, but i want to combine multiple signals, from eg. comparison objects, into a single signal so that it can be fed to a gate~. for example i have 1/2, 3/4, 5/6 coming from multiple sources, and to combine them into a single source for feeding as a control into a gate~. something like pack or funnel maybe but which doesn't output a list, but outputs the inlets in the order they're received (i.e. 1-2-3-4-5-6 sequentially, one after the other, or in the order they're received).

combining-multiple-signals

I'm not really sure what you're trying to do, maybe an example patch would help. In the meantime have a look at [cycle] which sends items to successive outlets.

Combining signals is not possible. You will need to deal with them individually.

Oh I think I see what you mean now. You might be looking for something like [multicore~] and [route~] which is sort of like a [pack] and [unpack] for signals. They're abstractions that can be found in Stefan Tiedje's 

Oh I think I see what you mean now. You might be looking for something like [multicore~] and [route~] which is sort of like a [pack] and [unpack] for signals. They're abstractions that can be found in Stefan Tiedje's abhaxions. I hope this helps.

this doesn't work, obviously, but hopefully gives you an idea of what i want. i looked for [multicore~] and [route~] in the link you provided (and also searched maxobjects.com), but they were no where to be found. i'll search around

hi,
this doesn't work, obviously, but hopefully gives you an idea of what i want. i looked for [multicore~] and [route~] in the link you provided (and also searched maxobjects.com), but they were no where to be found. i'll search around


In your example patch you talk of four bands, but I can see only three: bins 0-499, 500-1499, 1500-n. The condition not greater then 500 and not smaller then 1500 (or: smaller then 500 and greater then 1500) does never occur, at least not in this corner of the universe. This is how the three bands could be routed:

below is my original pfft~ subpatch in it's entirety, what i posted above was simply for illustration, the numbers were arbitrary and i didn't think about them, the patch was never meant to exactly represent reality. your first example was more what i want, i'd like to avoid a 2 channel gate for each division as i want to separate the spectrum into many (maybe 20+) subbands and i don't want hundreds of gate~ objects on the screen, both due to processor cycle saving and to reduce complexity. as you can see it's based purely on the crossover example in the tuts, breaks the signal into 4 subbands. already it's getting a bit complex for my liking, i can continue like this but i really don't want to get too far without considering alternatives for optimisation before it gets too complex. basically i guess i want a meths to reduce 2 or more [gate~] objects into one. apologies for not getting to this sooner, thanks again...

hi jvkr, thanks so much for your help,
below is my original pfft~ subpatch in it's entirety, what i posted above was simply for illustration, the numbers were arbitrary and i didn't think about them, the patch was never meant to exactly represent reality. your first example was more what i want, i'd like to avoid a 2 channel gate for each division as i want to separate the spectrum into many (maybe 20+) subbands and i don't want hundreds of gate~ objects on the screen, both due to processor cycle saving and to reduce complexity. as you can see it's based purely on the crossover example in the tuts, breaks the signal into 4 subbands. already it's getting a bit complex for my liking, i can continue like this but i really don't want to get too far without considering alternatives for optimisation before it gets too complex. basically i guess i want a meths to reduce 2 or more [gate~] objects into one. apologies for not getting to this sooner, thanks again...

Well in your example the [funnel] object doesn't understand signals. Only ~tilde~ objects are meant for signal processing. If you want to route different bins to different processes in your patch I would suggest using [index~] to read from a [buffer~] containing the [gate~] control values. Here's a quick example that has three output destinations. You need to click the [button] to initialise the patch.

thereishopeforus@hotmail.com wrote on Wed, 08 July 2009 19:46

thanks for your suggestions. as i said above, i think, was that what i posted was hypothetical in a sense, funnel i think as a signal funnel which accepts multiple signals and funnels them into a single stream, like a real life funnel. i apologise again for being obtuse, thanks for your time, i'll examine your suggestions in a a bit.

thereishopeforus@hotmail.com wrote on Wed, 08 July 2009 19:46Well in your example the [funnel] object doesn't understand signals. Only ~tilde~ objects are meant for signal processing. If you want to route different bins to different processes in your patch I would suggest using [index~] to read from a [buffer~] containing the [gate~] control values. Here's a quick example that has three output destinations. You need to click the [button] to initialise the patch.

thanks for your suggestions. as i said above, i think, was that what i posted was hypothetical in a sense, funnel i think as a signal funnel which accepts multiple signals and funnels them into a single stream, like a real life funnel. i apologise again for being obtuse, thanks for your time, i'll examine your suggestions in a a bit.


So I understand correctly that in your example you try to separate the spectrum in equally spaced frequency bands. There is no linear relationship between bins and frequency. This patch will help to work out this relationship:

Based on this relationship you could fill a buffer that binds a range of bins to a certain output. Then using index~ it is possible to read out these values to control a gate~. Is there a reason that you need to deal with the bands separately after they leave pfft~?

It seems like the reason your patch is so complicated is that you are only using [gate~ 2], so it requires a lot of gates to get all the routing right. If I understand your question correctly, you only need two gates--one for the real outputs and one for the imaginary outputs. If you make each one [gate~ 20] then they will be able to route 20 different bands, which will then need to be directed to 20 fftout~ objects. And as a couple of other people have said already, you will definitely want to store the routing information in a buffer, as it will greatly simplify things.

Once you've done that, you probably won't need to combine multiple signals.

hi, thanks again for suggestions. i'll look into the buffer~ index~ thing.

 Is there a reason that you need to deal with the bands separately after they leave pfft~?

yeah, basicaly i was making a spectral delay.

hi, thanks again for suggestions. i'll look into the buffer~ index~ thing. 

jvkr wrote on Thu, 09 July 2009 08:26 Is there a reason that you need to deal with the bands separately after they leave pfft~?

yeah, basicaly i was making a spectral delay.


You probably wanted to create a unique delay per band? This is not necessary. One tapin/tapout pair is enough to create a spectral delay. For each bin you need to specify an offset into the delay and that's about it.

yeah, thats right. could i still control the individual delay level/time/feedback/panning etc. per band with this method?

when you need feedback it will probably not work inside the fft.

otherwise i´d be curious for a patch, jvkr.

leonard wrote on Sat, 11 July 2009 03:24yeah, thats right. could i still control the individual delay level/time/feedback/panning etc. per band with this method?

otherwise i´d be curious for a patch, jvkr. 

Quote:otherwise i´d be curious for a patch, jvkr.

I leave it up to you to design a usefull UI around it.

brilliant, thank you so much. much better than the crappy little attempt i made.....

combining multiple signals