Clarification about poly~ and muting
I'm doing a deep overhaul of my VST management and so still have quite a few [print] objects around the place. My poly~ objects do automatic muting/unmuting and I just noticed that each time there's a mute or unmute, the particular instance in question seems to behave as if it was newly opened, i.e. the [loadbang] and [loadmess] objects are retriggered.
I'm wondering if this is really necessary (and if so, why) or whether it should be considered a bug.
This is with Max 6.1.7
Thanks,
D
if i am not missing something, that should definetly not happen.
ye, and could well be related to the new feature of poly~ not opening window of subpatchers in instances if the poly~ patch had been saved with said subpatch opened
the changelog said it better than me :
"poly~ : prevents opening window if subpatcher was saved with the window open"
I looked a little more closely --- turns out it's not the 'loadbang' that is retriggering, but actually the [thispoly~] is sending out a value (presumably the instance number) every time there is a mute/unmute. I wasn't expecting that to happen other than when a [bang] is sent in.
I already know how to have instances talk to each other --- that was part of my recent redesign ---- it's just that when I added some new abstractions to support "wireless" connections so that I can use a matrix to do arbitrary signal routing from one instance of a VST to another (whether the VSTs are inside one poly~ or in different poly~ objects) that I noticed this issue, which as I observed above is NOT a retriggering of the loadbang but rather the instance number being resent when there's a mute/unmute.
I just wasn't expecting that.
Incidentally, I try to avoid putting stuff "outside" ---- I like to have abstractions be as independent as possible rather than relying on external interaction to configure them.
aha, thispoly~, that i about what i exspected. :) yes thats intended that it reports again on any DSP on, just as dspstate~ does.
my next guess would have been that you are changing the voicenumbers from outside .. this of course would reload(bang) the instances.
Not sure what you mean by changing voice numbers. Basically I create (through some abstractions) a poly~ that will have 4 (say) instances of an object which has a [vst~] in it. I can then target the instances so as to load different VSTs and/or to send MIDI messages to the desired VST. The instance is muted automatically when the sound being generated becomes close to 0 (and stays there for several seconds). That muting (and unmuting) is performed inside the individual instances. When a mute or unmute occurs, the instance number is getting sent out through the [thispoly~], something I did not expect.
glad to know it's not a new bug :)
by "changing voice numbers" i'm sure he meant like, adding an instance, or removing it, or several, with the (voices [any number here]) message to poly~ - this recreates every instance
out of curiosity, are you routing sound parallelely (?!) through the poly~ instances ; or can you re-route sound from one instance into another ? If so, how do you send separate audio streams from several poly~ instances ?
hm, but i remember reading somewhere that it was not recommended to use send~ from inside a poly~, for reasons ?... or did i dream it ? or was that an issue years ago ?
No, once the poly~ are instantiated, they are never changed, I just change individual plugins. I don't have a problem with the instance number being sent out when there's a mute/unmute, I just didn't expect it, as (RAJA) notes, it's not documented.
I'm more concerned about the "not recommended to use send~ from inside a poly~". That's what I've been doing, and I'm sending audio from specific instances using [send~] whose target has a reference to the instance number. If that's going to bite me, then my whole design plan is f--ked. Anyone know more on this?
yes, if i ever read about that, it was in the forums, and if it's working for both of you, it might simply be my memory aging :) sorry for the noise !.
Well, I'll be testing this pretty deeply as I implement a matrix based router so I can connect arbitrary chains of VSTs together. I'll report back if I run in to any problems.
IIRC with send~/Receive~ and poly~ it's less of a can't and more of a probably shouldn't. Poly~'s inlets allow the DSP path to be parallelized, which can speed things up. You can't do this for DSP chains whose entry (and exit) points may change.
An utterly crack-brained way around this might be to check into the latency of writes to buffer~... I'm assuming that updates once per signal vector, so it would likely introduce a signal vector delay. This is a bad solution, but if it's the difference between parallelization and not and you need the CPU...
He says pre-coffee, coming up briefly for air from dissertation work.
If that's the case, then I'd like to lobby for being able to assign individual poly~ objects to specific cores.
Using send~/receive~ with [matrix~] lets me create arbitrary chains of VSTs on the fly as well as send stuff to different outputs on the fly, including the ability to do such things as route a VST piano to a VST phaser and have the phaser output go to FOH while the VST piano (without phasing) can go to band monitoring.
If that’s the case, then I’d like to lobby for being able to assign individual poly~ objects to specific cores.
Have you ever tested Alex Harker's "dynamic dsps" objects ? Never did myself, but they apaprently are aimed at doing just that...
and there are people who say ME having a bad taste when designing GUIs.
hey it seems that you are allowing feedback in that mixer matrix, isnt that a bit dangerous?
The graphics guru in my company has already replaced the graphics....I'm useless at creating nice looking graphics.
As for feedback, sure it's possible. But the benefits of being able to create multiple arbitrary audio chains from VSTs (or external devices) far outweighs the risk of unwanted feedback, which is easily avoidable by not turning the wrong knob
"hey it seems that you are allowing feedback in that mixer matrix, isnt that a bit dangerous?"
What would taste life without danger !
Kidding. However, sometimes you precisely want feedback. If you don't, then you can place safeguards. Still, a matrix~ like that would identify possible feedbacks and cut just those possible connections would be really cool ! No idea how to do that or if it would be possible (possibly ?)
As they say, perfection is the enemy of good enough. This matrix (well, a bigger one now that I have it working) along with some abstractions that make it trivial to create multiple poly objects each with a user defined number of instances lets me create and control pretty much any kind of synth combo that I need.
I'm a happy camper
yay:)
"which is easily avoidable by not turning the wrong knob"
that is exactly what you want to read in a user manual after the system has crashed.
No idea how to do that or if it would be possible
case 1: you just stick it together. then audio implodes already during patching the application.
case 2: you insert a delay in all loops. then the user ends up with a delay of infinite length as soon as he loops one loop into another.
case 3: you use seperate signal chains and implement a 2-way signal algorithm which modulates electronic circuits. you wouldnt want to program that in max.
after wanting such thing for long, i never really got the hang on beeing creative with bias v-box and TC spark back in the days. it seems to be a questionable concept to have an "effect matrix", no matter if with or without feedback options. once i tried to build a tree-formed effects rack with many inputs (but no feed back), that works out better.
-110
Not sure what point you're trying to make
I've done some stuff with feedback matrices, and I'd say that it's really important to have automatic gain control at the nodes.
The real fun happens when you're using multiple inputs into the matrix.
For my Master's thesis, I used an 8x8 matrix with four pitch shifters and four delays. The inputs into the pitch shifter nodes were determined by the amp envelope of the saxophone. I used compressors w
I've done some stuff with feedback matrices, and I'd say that it's really important to have automatic gain control at the nodes.
The real fun happens when you're using multiple inputs into the matrix.
For my Master's thesis, I used an 8x8 matrix with four pitch shifters and four delays. The inputs into the pitch shifter nodes were determined by the amp envelope of the saxophone, and this makes a huge difference since there can be multiple feedback paths and you can choose which part of the chain you're feeding into. I used compressors with negative slopes to keep things from blowing up.
My goal however is to have an easy way to route an arbitrary number of VSTs to other VSTs (if I want effects) and then to one or more separate outputs. This matrix mechanism seems like a very good way to do this. In general the knobs on the diagonal would always be at zero (although that wouldn't prevent a multi-vst loop) but generally I just won't be doing that.
Any chance you would share the code for your vst router? It might be a nice starting point for what I want to do....
For clarification, is it the case that each of the vsts in this scenario would run in its own thread? If not, I imagine I will need another solution anyway.
I was referring to the gui.
--but it looks like that will be 'a good excercise for the reader.'
Thanks!
-e