Closed markusschloesser closed 2 years ago
do we need to change if devices[0].parameters[param].value > 0
to if liveobj_valid(devices[0].parameters[param].value)
? probably
Will try to do later tonight
I tried again with the stable branch, and it did not happen again. So checked the source code and I cannot find any differences. Stange ๐ค
I'm just guessing from memory, but the "external instrument" doesn't have any "exposed parameters" does it?
Since you had just "added a device" to master track with none already there, and we had issues with those listeners before, it might be a similar issue where the code is just trying to "clear" the registered listeners before setting them again (with the new item)
But now after actually looking at the two methods involved meter_changestate() and check_md(), I'm confused. That code doesn't really make sense to me. I mean it kind of looks like a bunch of logic and almost no functionality. I mean, what does meter_changestate() "do"? What happens when any of those if
conditions evaluate False? The flip-side of that question is what is the significance of pass
when the logic evaluates True? I think pass
means "skip me, I have nothing to do" (equivalent to no-op), so, weird... a bunch of logic just to pass
and otherwise "doing nothing" when "not passing"?
Then, the error, line 868, in meter_changestate RemoteScriptError: elif self.check_md(4):
...says, it was thrown when the input to check_md() was 4. 4? What is the significance of checking the value > 0
of the second, third, and fourth parameters of devices[0]
in that situation?
Without understanding the higher-level purpose, I would have no idea how to "enhance" these methods with "new functionality" or fix any "bigger issues". But on the surface, it looks like all we need to do to guard against this error again is to guard that parameters[]
collection for length just like the devices[]
collection is guarded.
if len(devices[0].parameters) > param:
if devices[0].parameters[param].value > 0:
return 1 # if the first or only master track device parameter value is > 0
else:
return 0
else:
return 0
Quickly typed from my phone: External effects "sometimes" has 4 params, most of the times not, but yesterday I saw them. MCU can show meters, that's where the code probably comes from. Bur we can don't have that functionality.
I've seen the MCU do meters in "HUI mode" in the LCD strip. Interesting. I don't think there is any technical reason why the C4 couldn't display the same kind of "metering level" in its LCDs, if it needed to, like if you wanted to display the metering of "how much / how often" a compressor is "compressing" the signal over the "input signal level" encoder, you could (maybe) do that via these metering listeners? (in which case the C4 script wouldn't always pass
here...) Edit, or, for example, if you wanted to display the "channel level output" metering (top row) as well as the "slider level" value (bottom row). The hard part, I suspect would be actually implementing the "metering" for our script in "on display update" for example.
Edit 2:
External effects "sometimes" has 4 params, most of the times not, but yesterday I saw them.
Then that's an issue with "off by one" maybe? parameters[4].value
points to the fifth item in the list which wouldn't exist / would be out of bounds when a device only has 4 parameters.
I locally threw out (commented) all metering for the C4 last year, haven't seen an error since. Now I just gotta remember all that Github branching shit ๐๐
ended up just uploading via browser
first vomit since a long time! Steps to reproduce: put effect on masterbus (in my case "external audio effect")
Error msg:
and then:
those 2 repeat ad nauseam