[Fixed 2.6] Transport:stop May Not Stop From Transport:start_At

Renoise Tool Development
1

If you call this:

renoise.song().transport:start_at(renoise.song().selected_line_index)
renoise.song().transport:stop()

Renoise will start playing (too quickly given stop command does not have an effect)

2

Will have a look at this, but what you want/need is playback of a single line instead of start/stopping immediately, don’t you? If all this would be applied atomically, you would hear nothing at all, cause the song is played and stopped in one batch.

Would a “renoise.song().transport:play_current_line()” do the job? Would do what hitting return in the pattern editor does, without moving on to the next line with edit step.

3

NO! The code example was just so you could test it. The expected behaviour from this code would be silence indeed, and that is what I want.

Something similar to the “Enter” behavior would be greatly appreciated!

But this is unrelated to this bug.

4

Could we have instead?

renoise.song().transport:stop(line.index)

as it would be more flexible.

5

Also note that the regular start(mode) … stop() works as intended. (No playback is started)

6

The bug appears in my scale finder program.

  • When clicking on a chord button, the script enters the chord in the pattern editor and starts playback.
  • When releasing the chord button, the script stops playback.
  • This makes it possible to preview entered chords, while holding down the button.

Unfortunately, when just clicking on the chord button and releasing instantly, Renoise starts playback and doesn’t stop. Because the stop command issued, does not think renoise is playing at all.

7

If its just about scale finder, then what you !really! want is triggering notes for preview via the API, don’t you?

I often said I don’t want that in the API now, cause we only can offer “previews” with fuzzy timing. Scripts do not run in the real_time thread , so timing always will be off.

But if this results into even more hacks, we maybe should offer this but clear they are only previews. Make clear that you can not build your own sequencer with this, but just “preview” stuff.

Something like (=defaults):

renoise.song().trigger_note_for_preview(note_value, instrument=-1, track_index=-1, velocity=0x7f, duration_in_ms=1000)
or
renoise.song().trigger_note_on_for_preview(note_value, instrument_index=-1, track_index=-1, velocity=0x7f)
renoise.song().trigger_note_off_for_preview(note_value, instrument_index=-1, track_index=-1)

Should also not record anything into patterns, but just trigger the notes.
instrument_index=-1 uses the currently selected one. track_index=-1 uses the selected one

Definitely want the word “preview”, “fuzzy” in there somehow. Other ideas how we could do that?

8

It doesn’t even matter what I want.

If I call start(), and then stop() then the playback MUST be stopped, not started. Therefore, the start_at function must block until the playback is really started OR the stop must know that the playback is starting, and stop it before it starts to play.

It’s obviously a bug in start_at function, as normal start() function works perfectly.

Now about the note previews. That would be useful indeed. But I find the current preview very useful for myself, as I can hear the new chord in context with other pattern data. I would implement a preview which doesn’t enter notes too, which works when edit mode is turned off.

Maybe the play_preview function could take an array of notes as an input? So the chord is played together even though the start is not in perfect time?

Maybe even something as elaborate as?

preview_notes({  
 {  
 note = 'C-4',  
 velocity = 20,  
 length = 4 -- Four lines  
 },  
 note = 'C-5',  
 velocity = 20,  
 length = 4, -- Four lines  
 delay = 4 -- Starts after four lines  
 },  
 {  
 note = 'C-4',  
 velocity = 20,  
 length = 4, -- Four lines  
 delay = 8 -- Starts after 8 lines  
 },  
})

Either way, I am just fine with the current preview too as long as the stop() ACTUALLY STOPS THE PLAYBACK, every time, even when it’s called right after start_at!

9

Don’t worry. No need to argue. Of course it should.

10

But either way the elaborate preview I suggested would help many things:

  1. You can preview chords without the notes being placed erratically.
  2. You can preview some clips for arpeggiator, guitar chord emulator.
  3. The clip start is not realtime, but the clip itself is played in realtime thread so it is accurate.

This probably needs quite some work though and even if the idea is worth of consideration, I don’t see this being implemented in current version.

What this thing does is basically create another virtual pattern in memory and plays it back.

11

transport:stop(), transport:start_at() thing is fixed now.

And yes, lets skip the note trigger stuff for now. I am just putting myself into even more troubles. Lets solve this the “completely” in future…