dhjdhjdhj

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.

clarification-about-poly-and-muting

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

"poly~ : prevents opening window if subpatcher was saved with the window open"

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’m wondering if this is really necessary (and if so, why) or whether it should be considered a bug."

Some users need the ability to reset a gate or switch or the like each time dsp for poly~ is turned back on.

Not a bug. There are certain conveniences or design-options which are extended upon by having it this way, and it also encourages people to loadbang more efficiently outside the poly~ if they don't need this.

Some users need the ability to reset a gate or switch or the like each time dsp for poly~ is turned back on.
Not a bug. There are certain conveniences or design-options which are extended upon by having it this way, and it also encourages people to loadbang more efficiently outside the poly~ if they don't need this.


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.

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.

"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."

(that makes sense, and offers its own solutions...)

ah, i didn't see that before posting.
(that makes sense, and offers its own solutions...)


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.

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 ?

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 ?


"by “changing voice numbers” i’m sure he meant like"

HA! and there i thought he meant using the "target $1" message to target a specific mute message...

either way, it's correct that there's no bug here, but rather a need for more detailed docs.

it is to be expected that whenever a voice might be turned on and off, that there would be some kind of internal messaging to the voice that would allow users to register the change internally for certain contexts. thispoly~ resends the voice number because it simply outputs information from both its outlets(in other words, it's doing what it's supposed to do... whenever it outputs the mute flag out of its right outlet(which it will do as a result of any external muting messages), it will also output the instance number out of its left outlet).

vichug, for your further investigations, using the instance number from thispoly~ has many advantages which haven't always been documented clearly in the poly~ help stuff as far as i've seen(haven't looked at recently added examples, though...), here is just one of many ways(another way would be to setup a gate~ which is controlled by the instance number and use standard out~s)... to route instance-audio specifically:

HA! and there i thought he meant using the "target $1" message to target a specific mute message...
either way, it's correct that there's no bug here, but rather a need for more detailed docs.
it is to be expected that whenever a voice might be turned on and off, that there would be some kind of internal messaging to the voice that would allow users to register the change internally for certain contexts. thispoly~ resends the voice number because it simply outputs information from both its outlets(in other words, it's doing what it's supposed to do... whenever it outputs the mute flag out of its right outlet(which it will do as a result of any external muting messages), it will also output the instance number out of its left outlet).

vichug, for your further investigations, using the instance number from thispoly~ has many advantages which haven't always been documented clearly in the poly~ help stuff as far as i've seen(haven't looked at recently added examples, though...), here is just one of many ways(another way would be to setup a gate~ which is controlled by the instance number and use standard out~s)... to route instance-audio specifically:


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?

" i remember reading somewhere that it was not recommended to use send~ from inside a poly~"

can't seem to find this in the docs anywhere(hearsay like this often adds confusion when we don't know the exact source...).

it must've been on the forums, which can be misinterpreted often due to changing contexts(it could be the person who mentioned this was referring to how easily you can create an unwanted feedback connection... but if you're careful, you can get around it...)...

but i've definitely used send~/receive~ within poly~ and had no probs(then again, i can't claim to have tried every complex situation there is...). still, if it's an issue, the gate~ method also works well(but you can't use that to route audio 'between' instances without some sort of send~/receive~ network, i don't think... ya... max won't allow you to create a feedback connection from a poly~ outlet to the same poly~ inlet... and then use gate~ and selector~ internally to manage voice-to-voice communication... so you'd have to use send~/receive~ at some point...)...

can't seem to find this in the docs anywhere(hearsay like this often adds confusion when we don't know the exact source...).
it must've been on the forums, which can be misinterpreted often due to changing contexts(it could be the person who mentioned this was referring to how easily you can create an unwanted feedback connection... but if you're careful, you can get around it...)...

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 !.

i often have to parse out what i heard from the forums from what i learn by the docs in order to remember what to try out myself in order to confirm in any absolute/useable way.

since this is an important thing to test/confirm for myself, i went ahead and created a simple, changing send~/receive~ network for a poly~ to test it out(seems send~ and receive~ works fine... as far as i can see here...). I don't find any probs(crashes or unexpected behavior). But it might not be the exact, best, testing mechanism(i tried to negate feedback networks in the outer patch, but did things rather quickly so i may have glossed over something here or there...)... still, it might help others mod towards their own testing needs, so i post it here for posterity ;)

WARNING: TURN DOWN VOLUME ON YOUR COMP OR AUDIO I/O BEFORE STARTING UP THE PATCH :)

no prob, vichug.
i often have to parse out what i heard from the forums from what i learn by the docs in order to remember what to try out myself in order to confirm in any absolute/useable way.

WARNING: TURN DOWN VOLUME ON YOUR COMP OR AUDIO I/O BEFORE STARTING UP THE PATCH :)


damn. i couldn't figure out how to erase an attachment in an edit :p

so use the polysendtester1.zip link above rather than the other one(polysendtester1.zip is more easy on the ear, simply adding sines in different ways, whereas the older one, polysendtester.zip, is more noisy because i'm too obsessed with adding modulations to the phase inlet of cycle~ :p)

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.

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

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?"

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 ?)

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.

So here's the first version of that matrix with graphics done my one of my partners who, by the way, only saw Max for the first time this morning! It looks a bit better than my original attempt :-)

"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.

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.  I used compressors w


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.

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.

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.


https://cycling74.com/forums/easy-way-to-createedituse-vsts-in-return-can-you-help-me-reproduce-bugs/

--but it looks like that will be 'a good excercise for the reader.'

Clarification about poly~ and muting