[Doubt] How exactly does "transport:panic()" work?

Renoise Tool Development
1

I am using this “renoise.song().transport:panic()” to stop any sound before firing new notes:

Click to view contents 
--button pressed for VPD OSC Server
function vpd_osc_bt_pres( song, snci, ncl )
  song = renoise.song()
  snci = song.selected_note_column_index
  ncl = song.selected_line.note_columns
  --panic
  song.transport:panic() --avoid coupling for Mouse & MIDI Input!!!
  --note bar link (before)
  vb.views["NOT_SLIDER"].value = vb.views["VPD_VBX_RETURN_NOTE"].value
  --clear entire row (before)
  if ( vb.views["VPD_REC"].text == "REC" ) then
    ncl[snci]:clear()
  end
  --on note sound & insert note/pan/volume/ (after)
  vpd_osc_client:trigger_instrument( true, song.selected_instrument_index, song.selected_track_index, vb.views["VPD_VBX_RETURN_NOTE"].value, vb.views["VOL_SLIDER"].value )
end
--button released for VPD OSC Server
function vpd_osc_bt_rel( song )
  song = renoise.song()
  --off note sound & insert note-off (before)
  vpd_osc_client:trigger_instrument( false, song.selected_instrument_index, song.selected_track_index, vb.views["VPD_VBX_RETURN_NOTE"].value, vb.views["VOL_SLIDER"].value )
  --jump note (after)
  if ( vb.views["VPD_REC"].text == "REC" ) then
    vpd_search_step_2()--vpd_step()
  end
end

I am using OSC Server for sound and live recording, in a tool with a virtual piano and a chordpad.The doubt that I have is if I am correctly using the transport:panic().The objective is to avoid that the chords (or any note), continue to sound when you press several chords (or several notes), not superimpose different chords, because even when playing, I change octaves constantly. Released, it is responsible for stopping any chord, but it is possible to change chords without releasing the button, and that is an overlap problem…

I have done tests with the code and it seems to work well (surprisingly), both in the live recording (play song) and by entering the values in the pattern editor with the sound.Without using panic, the chords can overlap (sound, even writing in other contiguous columns …).

I was afraid thattransport:panic()stop all sounds from all tracks,but it’s not like that.Can anyone explain to me how**transport:panic()**works exactly?

The tool referred to is this (left window):

[sharedmedia=core:attachments:7549]

2

I don’t know the details of :panic(). I would only assume that it sends a note-off with all note values. It’s definitely not something I would use for terminating voices.

In OSC (like with MIDI), you terminate a voice by sending a note-off, very similar to how you send a note-on. Doing this properly implies that you remember what voices that are currently playing (already triggered with note-on). This, in turn, more or less implies that you structure your code with classes. (Otherwise, things will eventually become a bit ugly/messy, using some ad-hoc layout with ‘global’ tables and whatnot.)

My advise is to ‘encapsulate’ everything chord related to a chord class. Here is a simple explanation of the properties and methods that it could contain:

chord.button – contains/returns the viewbuilder button

chord.player – contains an “OscPlayer” class that takes care of playing/terminating voices, per below:

chord.player:play()

chord.player:stop()

chord.player.is_playing – can be used to avoid bugs in case a button is clicked consecutively.

other cool methods to implement:

chord:flash_button()

chord:stop_flash_button()

If you haven’t started to make classes, this might be the time :slight_smile:

EDIT: I noticed now that we’ve already dealt with this topic here https://forum.renoise.com/t/solved-help-code-for-play-stop-specific-note-of-a-instrument-is-po/47116 so maybe I didn’t contribute anything now. Anyhow, I just want to point out that using :panic() doesn’t look very nice to me :slight_smile:

3

@Joule. Hi & Thanks! :slight_smile:

Now I am in an interesting situation. When I made GT16-Colors,I really did not know some limits of the Renoise API. When I came across some, I had to hold myself almost out for obligation, in a feeling of not being able to move any further.

With this new tool, VPDpro (a 95% finished!),I have built the code knowing these limitations to avoid them, with the focus of making everything work exactly as I wish, even if the solutions are not as elegant or correct as possible. The important thing is that it works, how it is “something secondary”.However, I have also tried to better order the code and make it more elegant and “correct”.

I’ve been testing the panic function, both in live recording and in simple editing (enter notes or chords).What I’ve deduced is that panic stops all the notes playing on the selected track, not all other tracks. It looks a lot like what I need and it is very fast.As I have focused my “Chordpad”,is able to input up to 59 chords, with 9 octaves (0-8), chords of up to 7 notes, with base note on any semitone (C-, C#, D-, …, B-) with any octave.This means that you can change the semitone by keeping the selected chord or even change chords by keeping the last semitone.Then you can play and record live up to a total of 59 x 9 x 12. More than 6300 chords.Ok, in addition, you can change the octave and also the instrument while recording liveon the fly, even using MIDI Input.

The problem is that I do not know how to approach it to avoid all cases. Maybe a function that stops all notes (they are 120) each time you play a new note or chord.Then, the trigger to stop the notes is to press, not to release.The correct thing would be to stop only the notes that are really sounding, without touching the rest.

I would have to think all this in greater depth for a possible future version of the tool, even attending the classes. For now, panic does the job.

@Renoised.I did not know that you liked so much the topic of the panic() ;).Are you studying code to build your RAS?Do not forget to comment on your impressions. The code is exciting.

4

To each his own, and all in due time :slight_smile:

(I’ve found that the main reason for trying to do well written code, is that it becomes a lot easier to understand it 6 months from now, when revisiting it to add some feature or fix some bug. So, not only does it help in avoiding bugs, but also makes the code easier to maintain.)

5

To each his own, and all in due time :slight_smile:

(I’ve found that the main reason for trying to do well written code, is that it becomes a lot easier to understand it 6 months from now, when revisiting it to add some feature or fix some bug. So, not only does it help in avoiding bugs, but also makes the code easier to maintain.)

Yes, this should be the first rule of any programmer.Write the code in an orderly and correct way to understand it months later.In the beginning, it is not so that another understands it, but so that the same programmer knows to deal with him later. Probably meeting this rule, any programmer understand your code.This also implies, “leave it ready” to add things later…

6

@Raul

I only spotted the thread cause it was visible as a new post from the index page, so I thought I’d pop in and see what you were up to :stuck_out_tongue:

Looks very cool B)

^^ ^^ ^^ ^^ ^_^I see we understand each other…