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

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.).

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.

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.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.