wait command not working

[SiskaAdam]

When I run this script:

integra.set ( "Distortion", "mix", integra.get ( "OnsetDetector", "onset" ) * 0.01 ) while integra.get ( "Distortion", "mix" ) > 0.0 do integra.set ( "Distortion", "mix", integra.get ( "Distortion", "mix" ) - 0.01 ) integra.wait(0.01) end

I get this error:

error: Can't find endpoint: Detection.Track.Block.wait

error: [string "integra.set ( "Distortion", "mix", integra...."]:4: attempt to call global 'wait' (a nil value)

It seems that the wait command is not found by the interpreter.

[jamiebullock]

That's correct. integra.wait() is actually deprecated and I thought we'd removed it from the documentation, but I'm fact there are some traces of it, which I guess you found. I'll leave this issue open until the documentation is completely up-to-date.

BTW, you can now use . syntax, e.g. TapDelay1.delayTime = 3.

[SiskaAdam]

Thanks. If integra.wait() is now deprecated, what are we supposed to use instead?

[jamiebullock]

What are you trying to do? I mean musically.

It's possible to make a script sleep using Lua's os.clock() function. However, it's important to realise the consequences of this. Integra scripts run synchronously, so they will block any further parameter changes until they finish executing. Such parameter changes are added to a queue, so will execute immediately after the script has finished.

I've uploaded a demo block to show a script with a sleep function example, also below.

The "right" way to handle timing in Integra Live is outside the scripting environment, e.g. using the timeline, scenes etc. We are looking to extend timing functionality through the UI rather than through script, so if there a specific musical task you are trying to achieve, then let us know and we'll try to develop the UI to support it.

local clock = os.clock

local function sleep(n)  -- seconds
   local t0 = clock()
   while clock() - t0 <= n do
   end
end

for i = 1, 5, 1 do
    TestSource1.outLevel = 1
   sleep(1)
    TestSource1.outLevel = 0
   sleep(1)
end

[SiskaAdam]

Thank you, Jamie.

You're right, if scripts run synchronously, then my solution is not really optimal.

Here's the situation: I'm creating a VERY simple project to demonstrate different simple detection methods to students. It contains a pitch detector, an envelope follower and an onset detector to analyse the incoming sound. Then, there is a sinusoidal test tone (whose pitch and amplitude is controlled by the pitch detector and the envelope follower), and the test tone is fed into an audio effect (I choose distortion, but could be any arbitrary effect). The idea is that, whenever the onset detector changes (i.e. an onset is detected), they should trigger a decaying envelope for the 'mix' of the applied effect. Ideally, I could create a scene and an envelope, but in that case, the students wouldn't be able to experiment with the parameters (since I can't add a 'partial' envelope to a single block, i.e. after the decaying envelope finishes running, they wouldn't be able to change the mix parameter).

What do you suggest for this specific scenario?

Thanks, Ádám

[leightonhargreaves]

Hi Ádám

In our latest internal version, I think you can achieve the behaviour you are looking for using a scene and an envelope, We have added a new feature to override the padlock on locked controls by holding down cmd - this would allow you to change the mix parameter even though it is also controlled by an envelope.

You would need to create a project-level script along the lines of

Player1.scene = "myScene"

and create a route from your onset detection to the script's trigger.

I've just fixed a problem which was preventing scenes from being activated via script - Jamie will make a new version available to you including this new functionality

[SiskaAdam]

Hi,

I already realized this solution, which is actually achievable with the current stable as well (I did it), although needs some tricks (what I have now is a script that sets a specific MIDI note, and the scene is being triggered by that particular MIDI note). However, this is not really the solution that I am looking for, since adding an envelope would fix the 'mix' setting, so my students won't be able to modify the mix with the mouse. The idea is that the patch should allow control by mouse for all parameters, but specifically, when an onset is detected, the onset should trigger a decaying envelope. However, after the envelope finished execution, it should not 'block' any setting from the mouse.