bug? oscout causing output on load

[newtfish]

Ok, so I have created a test patch.

Its just a simple script inside a pads object which sends oscout.

As you can see when you load the template from the editor, it outputs some OSC initial values, without any interaction whatsoever.

the output i get from max is "print: /thisshouldntbesending 0. 0."

Why is this sending anything? Surely, oscout should only send when something is pressed. Its very strange that oscout would work this way, just outputting random values when the template loads.

It has also not changed since the new update. It seems the same behaviour as I tested on v4. It has always been like this, but I have no idea why.

[newtfish]

heres another one.

If I create a custom button and a knob, put a script inside the custom button "Knob.x = 0.5;", then load the template, it outputs values???

Why would it output these values if nothing is pressed? I havent specified for it to do anything onload.

There seems to be no way around this.

[Macciza]

Hi
As I said earlier I had a bit of a look and their may be some oddities going on... To be referred to support . .

Here is a way around it using flags - the flag is set, and then checked in the OSC script, only running if it is 0
This could be viewed as a 'workaround' or equally as a good 'sanity check' to avoid unwanted action
Oh and the names I picked for functions and vars aren't the best either . . .

[nick_liine]

It is normal that a script set to 'On Expression = x' runs immediately on startup. x is undefined, when the template is loaded x is set to the value saved with the template. The script now runs because x has been set to something. The only way to avoid this is either to use standard OSC Mapping, or a flag as Macciza suggests.

However, for the flag method, there is a bug where OnLoad scripts don't overwrite expressions set to a constant value. I believe this is the cause of the flag failing. Should be fixed in 5.1

[oldgearguy]

It is normal that a script set to 'On Expression = x' runs immediately on startup. x is undefined, when the template is loaded x is set to the value saved with the template. The script now runs because x has been set to something. The only way to avoid this is either to use standard OSC Mapping, or a flag as Macciza suggests.

However, for the flag method, there is a bug where OnLoad scripts don't overwrite expressions set to a constant value. I believe this is the cause of the flag failing. Should be fixed in 5.1

Can you please take a minute to further explain these two things? I think I have been trying to fix bugs/code around behavior due to these exact things.

Second first -- what do you mean "Onload scripts currently don't overwrite expressions set to a constant value?"
Does this mean if I have a global variable or a variable inside a container set to some nominal value that currently my onload() script will not change it?
Example - in my project I have a global variable called machine_count and it is set to 0; During onload() I check some things and if I find a device connected, I change machine_count to 1. Are you saying this change does not happen? If that is true, does defining machine_count and not setting it to an initial value work?

First second -- it sounds like you are saying every script in a template that uses 'On Expression = x' is executed once on startup. My questions are -- is this behavior going to remain or is this considered a bug? Next - does it matter what the trigger type is? (any/up/down/zero, etc). Next - what about other 'On Expression = ' scripts like z or user-defined variables? Finally - is there any guarantee these scripts execute before/during/after any onload() scripts? In other words - do we have to code all On Expression scripts to handle the possibility they will be called once before the onload() scripts have run?

thanks for clearing up any of this.

[nick_liine]

It is normal that a script set to 'On Expression = x' runs immediately on startup. x is undefined, when the template is loaded x is set to the value saved with the template. The script now runs because x has been set to something. The only way to avoid this is either to use standard OSC Mapping, or a flag as Macciza suggests.

However, for the flag method, there is a bug where OnLoad scripts don't overwrite expressions set to a constant value. I believe this is the cause of the flag failing. Should be fixed in 5.1

Can you please take a minute to further explain these two things? I think I have been trying to fix bugs/code around behavior due to these exact things.

Second first -- what do you mean "Onload scripts currently don't overwrite expressions set to a constant value?"
Does this mean if I have a global variable or a variable inside a container set to some nominal value that currently my onload() script will not change it?
Example - in my project I have a global variable called machine_count and it is set to 0; During onload() I check some things and if I find a device connected, I change machine_count to 1. Are you saying this change does not happen? If that is true, does defining machine_count and not setting it to an initial value work?

That is correct. On Load scripts will not overwrite constant variables. This is a bug that will be fixed in 5.1. If you create a variable in Lemur Editor (for example 'machine_count') but you do not type in a value, then the On Load script should be able to overwrite it in version 5.0.3. The bug only applies if you set an initial constant value to your variable.

First second -- it sounds like you are saying every script in a template that uses 'On Expression = x' is executed once on startup. My questions are -- is this behavior going to remain or is this considered a bug? Next - does it matter what the trigger type is? (any/up/down/zero, etc). Next - what about other 'On Expression = ' scripts like z or user-defined variables? Finally - is there any guarantee these scripts execute before/during/after any onload() scripts? In other words - do we have to code all On Expression scripts to handle the possibility they will be called once before the onload() scripts have run?

The default value for an expression is zero. On Expression scripts are executed on startup if the value of the expression is non-zero. Lemur has behaved like that since day one, as a non-zero value for the expression counts as a change from the default. Is this behaviour a big problem?

[oldgearguy]

It is normal that a script set to 'On Expression = x' runs immediately on startup. x is undefined, when the template is loaded x is set to the value saved with the template. The script now runs because x has been set to something. The only way to avoid this is either to use standard OSC Mapping, or a flag as Macciza suggests.

However, for the flag method, there is a bug where OnLoad scripts don't overwrite expressions set to a constant value. I believe this is the cause of the flag failing. Should be fixed in 5.1

Can you please take a minute to further explain these two things? I think I have been trying to fix bugs/code around behavior due to these exact things.

Second first -- what do you mean "Onload scripts currently don't overwrite expressions set to a constant value?"
Does this mean if I have a global variable or a variable inside a container set to some nominal value that currently my onload() script will not change it?
Example - in my project I have a global variable called machine_count and it is set to 0; During onload() I check some things and if I find a device connected, I change machine_count to 1. Are you saying this change does not happen? If that is true, does defining machine_count and not setting it to an initial value work?

That is correct. On Load scripts will not overwrite constant variables. This is a bug that will be fixed in 5.1. If you create a variable in Lemur Editor (for example 'machine_count') but you do not type in a value, then the On Load script should be able to overwrite it in version 5.0.3. The bug only applies if you set an initial constant value to your variable.

First second -- it sounds like you are saying every script in a template that uses 'On Expression = x' is executed once on startup. My questions are -- is this behavior going to remain or is this considered a bug? Next - does it matter what the trigger type is? (any/up/down/zero, etc). Next - what about other 'On Expression = ' scripts like z or user-defined variables? Finally - is there any guarantee these scripts execute before/during/after any onload() scripts? In other words - do we have to code all On Expression scripts to handle the possibility they will be called once before the onload() scripts have run?

The default value for an expression is zero. On Expression scripts are executed on startup if the value of the expression is non-zero. Lemur has behaved like that since day one, as a non-zero value for the expression counts as a change from the default. Is this behaviour a big problem?

Thanks for explaining these things. Short answer -- no it is not a problem. I just want to know what happens so I can create scripts that operate correctly. One of the slightly frustrating things about creating templates in this environment is the incomplete amount of information about how the environment works. There appear to be side effects to some behaviors. This can be a good thing in music creation, but in programming, you want things to behave exactly the way they are supposed to behave. Without knowing that non-zero expressions cause On Expression scripts to trigger on startup, templates can seem to have random behavior, depending on the state they were in when saved and what happens during the initialization and onload() phases.

As far as the initialization bug goes - again, good programming practice dictates that you ensure variables have a defined, valid value on program startup. Purposely leaving variables uninitialized is not a natural thought. I can work either way, but I need to know how it is. I will continue coding for the 5.1 environment and live with it during testing until it comes out.

I appreciate you taking the time to respond to my questions because it does help build better products.

[newtfish]

It is a problem if youre doing a live set for instance:

1) You upload a template to your Lemur half way through the set
2) You then initialise the template by sending a bunch of values to it
3) But Lemur is sending back it's default values at the same time, which causes all hell to break loose.

a) You cannot set initial values straight after a template has been loaded (lemur sends back its own, particularly with pads or switches, or anything with a script in it really)
b) Lemur sends values that cause your receiver to potentially have massive problems (such as turning the volume all the way up, or just generally setting values that you simply dont want, or shouldnt be happening)

Imagine Im playing on a funktion 1 sound system. I upload a template. It sends the volume back to my receiver and turns it all the way up and the sound system is blown. Not funny :/

I have actually solved this somehow with some scripting workarounds and also setting the script to "message sent when value reaches or leaves zero", but its far from ideal... it would also be great to have confidence that this isnt going to creep in again, with another update. Its worth nothing though, that it has always been like this and seems to have nothing to do with the update to v5

[oldgearguy]

I understand your issues. Since I am doing an editor that pulls information from the synth to display the current values, I end up changing the x vlaue of a knob/slider in 2 ways:

1 is by user interaction and
2 is by pulling MIDI info back.

I also have scripts that trigger on an x change that send MIDI info back to the synth to update it. As you can guess - that causes some nasty issues if the x change from a patch pull updates x which then generates a MIDI send back to the synth.

My solution was to put a sendMIDI flag in and whenever I update an x value by pulling back MIDI data, the sendMIDI flag is set to false. Then the x value is updated and the update script checks the flag and doesn't send that update back to the synth.

I also have a global "I'm starting up don't send any MIDI back now" flag that I wrap around the midiout() command in my central MIDI output script. During startup and onload() script processing this flag prevents MIDI data from coming out of the Lemur and after all initialization is done, I reset that flag to allow MIDI to flow out.

[newtfish]

Hi oldgearguy,

Im interested to find out how you use the "startup dont send midi" function. From what I can see, if I use an "init" script to determine when the template has loaded, this actually fires before some of the objects are fully loaded, so there is no way to know the "end point" of when everything is loaded. Are you using a timer for this or something else?