Problem with .transport.playing & .transport:start()

[Raul (Raul (ulneiz))]

Documentation: Renoise.Song.API.lua

– Playing.
renoise.song().transport.playing, _observable
→ [boolean]

renoise.Transport.PLAYMODE_RESTART_PATTERN
renoise.Transport.PLAYMODE_CONTINUE_PATTERN
– Mode: enum = PLAYMODE
renoise.song().transport:start(mode)
– start playing the currently edited pattern at the given line offset
renoise.song().transport:start_at(line)
– start playing a the given renoise.SongPos (sequence pos and line)
renoise.song().transport:start_at(song_pos)

– stop playing. when already stopped this just stops all playing notes.
renoise.song().transport:stop()

The function to solve it:

For some reason that I can’t understand, using .transport:start() doesn’t always work (or something else related fails). But it does work if the function runs with a slight delay. Here is a solution that I have written.

--play/stop
local ASC_PLAY_MODE=1
local function asc_play_delay()
  if not renoise.song().transport.playing then
    renoise.song().transport:start(ASC_PLAY_MODE)
  else
    renoise.song().transport:stop()
  end
  if (rnt:has_timer(asc_play_delay)) then
    rnt:remove_timer(asc_play_delay)
  end
end
function asc_play_stop(mode)
  --print("play",renoise.song().transport.playing)
  if (not rnt:has_timer(asc_play_delay)) then
    ASC_PLAY_MODE=mode
    rnt:add_timer(asc_play_delay,10)
  end
end

Supposedly, to use .transport: start () the boolean .transport.playing needs to be checked beforehand to be able to control the play and stop from a single button in the viewbuilder, or an associated physical key.

Apparently I have had the same problem in several of my tools.

The function that returns problems

For example, this function return problems:

function asc_play_stop(mode)
  --print("play",renoise.song().transport.playing)
  if not renoise.song().transport.playing then
    renoise.song().transport:start(mode)
  else
    renoise.song().transport:stop()
  end
end

Interestingly, I have figured out the solution using this function and activating the line:

• print(“play”,renoise.song().transport.playing)

This line within the function generates a small delay. Thanks to him, the function will work correctly. Otherwise it will occasionally fail (for example, when inserting notes after stopping playback from the tool.).

[Raul (Raul (ulneiz))]

Another better and absurd solution to this strange problem would be this function:

function asc_play_stop(mode)
  --print("play",renoise.song().transport.playing)
  if (not renoise.song().transport.playing) then
    renoise.song().transport:start(mode)
    return
  end
  if (renoise.song().transport.playing) then
    renoise.song().transport:stop()
  end
end

So this function is the best solution I have tried to be able to control play & stop from the same button. If anyone runs into this problem with if else end, here is this solution using return and two if then end.

The only thing I can think of as to what is causing the problem is that Renoise does not change the “play state” to the “stop state” in real time, but has a very very small delay. Or maybe the boolean state change of .transport.playing also has a little delay.

[4tey]

@Raul

The only thing I can think of as to what is causing the problem…

Renoise is threaded. Lua and Renoise aren’t completely synced to each other. Another example of this:

https://forum.renoise.com/t/get-pattern-position-in-sequencer/

Causes awful confusion/problems. We as programmers naturally assume that when we read a variable/object (particularly with the transport) from thread lua it is all up to date with the internal state variable/object thread of Renoise.