handling paramchanges when machine output is not connected
handling paramchanges when machine output is not connected
lately i've observed that when a machine is not connected to a chain that leads to master, its work() (and more importantly) tick() functions are not called. this leads to situation where the user changes a parameter in the gui while the machine is disconnected, then connects up the machine but the parameter of course didn't change internally. imho this is not the expected behaviour the user wants, the display and the internal values are now out of sync and he has to move the slider again to get the machine to update.
i can't remember if this was always the case with buzz or if its something new, possibly a bug?
if its not a bug, how are machine developers supposed to handle such events ?
i'm still on 1410 btw, trying to finish this machine before i update.
i can't remember if this was always the case with buzz or if its something new, possibly a bug?
if its not a bug, how are machine developers supposed to handle such events ?
i'm still on 1410 btw, trying to finish this machine before i update.
- Reefer Sutherland
- Posts: 96
- Joined: Thu Nov 24, 2011 3:17 pm
- Contact:
Re: handling paramchanges when machine output is not connect
It is how I expect it to behave... It's always been like this.
Consider disconnected machines inactive, disconnected, not in use.
If you don't want sound from it, just connect it to an AuxSend or whatever...
Consider disconnected machines inactive, disconnected, not in use.
If you don't want sound from it, just connect it to an AuxSend or whatever...
Re: handling paramchanges when machine output is not connect
this is more of a developer than a user question.
also, i disagree, the behaviour is totally unexpected for the user. and i don't like it as a developer because i can't currently seem to handle these cases (no tick() called means i can't update my internal state).
Also, control machines seem to get tick calls and they are not connected to anything (peerctrl etc).
Do i have to maybe tell buzz that my efx is also a control machine (it isn't really..but that might work?) ?
Calling tick() while its disconnected shouldn't hurt ?
Or maybe the machine could signal to buzz that it wants tick() calls while its disconnected.
also, i disagree, the behaviour is totally unexpected for the user. and i don't like it as a developer because i can't currently seem to handle these cases (no tick() called means i can't update my internal state).
Also, control machines seem to get tick calls and they are not connected to anything (peerctrl etc).
Do i have to maybe tell buzz that my efx is also a control machine (it isn't really..but that might work?) ?
Calling tick() while its disconnected shouldn't hurt ?
Or maybe the machine could signal to buzz that it wants tick() calls while its disconnected.
Re: handling paramchanges when machine output is not connect
That's just the way it is. Generators Tick but don't Work if they're not connected, effects do neither. I don't think control machines actually tick, it's just that most of them are generators and so they tick anyway. You can add the flag MPF_TICK_ON_EDIT to a parameter declaration which forces a Tick() when you type a value in a pattern but I'm not sure if it works when a slider is moved.
If you could describe your problem in detail then we might be able to suggest a solution. Buzz has always behaved this way and it's unlikely that you've got a unique problem.
disclaimer: I could be wrong about any of the above
If you could describe your problem in detail then we might be able to suggest a solution. Buzz has always behaved this way and it's unlikely that you've got a unique problem.
disclaimer: I could be wrong about any of the above
Re: handling paramchanges when machine output is not connect
yes the problem occurs when you move a slider when the effect is unconnected.
this problem is not unique to my machine. it happens with ALL effect machines, which is why i suggest it be changed, because its really not good from a user perspective to NOT react to parameter changes and let the GUI and the internal state of the machine get out of sync. If its not fixable for all machines because of backwards compat issues, i suggest that the machine may ask that buzz please-call-tick-when-unconnected by setting a flag or so. i don't see why this privilege should be reserved for generators, it confuses even me when i use my own machines, nobody wants to remember that he can only fiddle with a slider if the effect is connected.
I'm pretty convinced by now that there is no other solution....but if you have ideas, please tell.
oskari ?
this problem is not unique to my machine. it happens with ALL effect machines, which is why i suggest it be changed, because its really not good from a user perspective to NOT react to parameter changes and let the GUI and the internal state of the machine get out of sync. If its not fixable for all machines because of backwards compat issues, i suggest that the machine may ask that buzz please-call-tick-when-unconnected by setting a flag or so. i don't see why this privilege should be reserved for generators, it confuses even me when i use my own machines, nobody wants to remember that he can only fiddle with a slider if the effect is connected.
I'm pretty convinced by now that there is no other solution....but if you have ideas, please tell.
oskari ?
- Reefer Sutherland
- Posts: 96
- Joined: Thu Nov 24, 2011 3:17 pm
- Contact:
Re: handling paramchanges when machine output is not connect
I'm sure this is a dev-question..
But you you did say it was unexpected and unwanted for a user, which is why I replied.
It's not unusual for me (or most of the people using Buzz I think), so it might not be a big problem
But you you did say it was unexpected and unwanted for a user, which is why I replied.
It's not unusual for me (or most of the people using Buzz I think), so it might not be a big problem
Re: handling paramchanges when machine output is not connect
i just think its wrong, and it confuses me even as a >10 year buzz user. I often tried to change parameters while some efx was unconnected, connected the machine, wondered why the parameters displayed didn't match the sound i heard, and later realized i had to change the params again. I don't see a good reason to keep this confusing behaviour alive.
for example when i start a new song, i start by adding LOTS machines and tweaking their parameters, and only later bother to connect em up. only to realize it didn't work. Wanting to change parameters before you connect something up is a pretty basic need imho.
for example when i start a new song, i start by adding LOTS machines and tweaking their parameters, and only later bother to connect em up. only to realize it didn't work. Wanting to change parameters before you connect something up is a pretty basic need imho.
Re: handling paramchanges when machine output is not connect
i just tried that, doesn't seem to work for slider changesIXix wrote:You can add the flag MPF_TICK_ON_EDIT to a parameter declaration which forces a Tick() when you type a value in a pattern but I'm not sure if it works when a slider is moved.
Re: handling paramchanges when machine output is not connect
W0000000T
MIF_CONTROL_MACHINE
just tested this flag, setting this makes buzz call tick even when the effect is disconnected, i don't know if its a proper / good solution tough? Oskari?
MIF_CONTROL_MACHINE
just tested this flag, setting this makes buzz call tick even when the effect is disconnected, i don't know if its a proper / good solution tough? Oskari?
Re: handling paramchanges when machine output is not connect
ok, so i had to remove the flag again, it was causing problems:
MIF_CONTROL_MACHINE can't send control changes to other MIF_CONTROL_MACHINE, and my machine relies on that to send control changes to itself (for SOLO)..
i really need a flag for call-tick-when-disconnected..
MIF_CONTROL_MACHINE can't send control changes to other MIF_CONTROL_MACHINE, and my machine relies on that to send control changes to itself (for SOLO)..
i really need a flag for call-tick-when-disconnected..
Re: handling paramchanges when machine output is not connect
for the devs / people following this or stumbling over the same issue:
<@oskari> yeah it's not easy to fix unfortunately
<@[UNZ]> what issues would it cause ?
<@oskari> don't know, that's the problem
<@[UNZ]> could it be an engine option ?
<@[UNZ]> or machine flag, but then we have two sets of behaviours, some will update some not..
<@oskari> i'll think about it
<@[UNZ]> thx a lot
Re: handling paramchanges when machine output is not connect
If that were true, no peer machine could control any other.UNZ wrote:MIF_CONTROL_MACHINE can't send control changes to other MIF_CONTROL_MACHINE
Re: handling paramchanges when machine output is not connect
IXix wrote:If that were true, no peer machine could control any other.UNZ wrote:MIF_CONTROL_MACHINE can't send control changes to other MIF_CONTROL_MACHINE
Code: Select all
#define MIF_CONTROL_MACHINE (1<<6) // used to control other (non MIF_CONTROL_MACHINE) machines
at least it didn't work when i was sending control changes to my own machine, maybe it works if you sent to another....
always wondered how buzz handles peer to peer.
Re: handling paramchanges when machine output is not connect
All my peers are MIF_CONTROL_MACHINE and I'm pretty sure all btd's are too. I'm also pretty sure that control machines can control themselves, although I haven't done any of that lately and not all machines allow it. Trying to remember which ones do...UNZ wrote:well then the comment in machineinterface.h must be wrong ?Code: Select all
#define MIF_CONTROL_MACHINE (1<<6) // used to control other (non MIF_CONTROL_MACHINE) machines
at least it didn't work when i was sending control changes to my own machine, maybe it works if you sent to another....
always wondered how buzz handles peer to peer.
Re: handling paramchanges when machine output is not connect
PeerLFO is MIF_CONTROL_MACHINE and can control itself. You must be doing something wrong.IXix wrote:I'm also pretty sure that control machines can control themselves, although I haven't done any of that lately and not all machines allow it. Trying to remember which ones do...
Re: handling paramchanges when machine output is not connect
well, my machine is an efx...that may be the problemIXix wrote:PeerLFO is MIF_CONTROL_MACHINE and can control itself. You must be doing something wrong.IXix wrote:I'm also pretty sure that control machines can control themselves, although I haven't done any of that lately and not all machines allow it. Trying to remember which ones do...
i know i'm not doing anything wrong because control changes to itself works without the flag.
anyway, its not the flag i need. I hope oskari finds a way to fix it / add a new flag.
Re: handling paramchanges when machine output is not connect
No, I just checked PeerEnv and it can control itself too. Strange, I wonder what the problem is.UNZ wrote:well, my machine is an efx...that may be the problem
Re: handling paramchanges when machine output is not connect
i'm out of ideas, the only other difference is my machine is multi io. i'll tripple check tomorrow whats going on if i insert that flag...IXix wrote:No, I just checked PeerEnv and it can control itself too. Strange, I wonder what the problem is.UNZ wrote:well, my machine is an efx...that may be the problem
EDIT: OK, the sliders move now, tick gets called when i use the flag MIF_CONTROL_MACHINE and the controlchangesimmedeate() work!
but i get no sound (probably a problem with my machine tough)... dunno what was up before, i updated buzz from 1410. I may also just have been confused. Sorry
i'm not even sure i should abuse this flag, guess i'll wait what oskari comes up with.