Page 1 of 1
handling paramchanges when machine output is not connected
Posted: Mon Jan 02, 2012 1:27 am
by UNZ
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.
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 2:04 am
by Reefer Sutherland
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...
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 3:30 am
by UNZ
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.
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 9:28 am
by IXix
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
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 11:05 am
by UNZ
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 ?
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 11:24 am
by Reefer Sutherland
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
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 11:31 am
by UNZ
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.
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 11:49 am
by UNZ
IXix 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.
i just tried that, doesn't seem to work for slider changes
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 11:54 am
by UNZ
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?
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 12:45 pm
by UNZ
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..
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 2:02 pm
by UNZ
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
Posted: Mon Jan 02, 2012 6:02 pm
by IXix
UNZ wrote:MIF_CONTROL_MACHINE can't send control changes to other MIF_CONTROL_MACHINE
If that were true, no peer machine could control any other.
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 6:35 pm
by UNZ
IXix wrote:UNZ wrote:MIF_CONTROL_MACHINE can't send control changes to other MIF_CONTROL_MACHINE
If that were true, no peer machine could control any other.
Code: Select all
#define MIF_CONTROL_MACHINE (1<<6) // used to control other (non MIF_CONTROL_MACHINE) machines
well then the comment in machineinterface.h must be wrong ?
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
Posted: Mon Jan 02, 2012 6:42 pm
by IXix
UNZ wrote:
Code: Select all
#define MIF_CONTROL_MACHINE (1<<6) // used to control other (non MIF_CONTROL_MACHINE) machines
well then the comment in machineinterface.h must be wrong ?
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.
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...
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 6:48 pm
by IXix
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...
PeerLFO is MIF_CONTROL_MACHINE and can control itself. You must be doing something wrong.
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 6:54 pm
by UNZ
IXix wrote: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...
PeerLFO is MIF_CONTROL_MACHINE and can control itself. You must be doing something wrong.
well, my machine is an efx...that may be the problem
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
Posted: Mon Jan 02, 2012 8:33 pm
by IXix
UNZ wrote:well, my machine is an efx...that may be the problem
No, I just checked PeerEnv and it can control itself too. Strange, I wonder what the problem is.
Re: handling paramchanges when machine output is not connect
Posted: Mon Jan 02, 2012 8:46 pm
by UNZ
IXix wrote:UNZ wrote:well, my machine is an efx...that may be the problem
No, I just checked PeerEnv and it can control itself too. Strange, I wonder what the problem is.
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...
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.