Jump to content


Photo

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

transport:panic() panic

  • Please log in to reply
7 replies to this topic

#1 Raul (ulneiz)

Raul (ulneiz)

    Guruh Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPip
  • 965 posts
  • Gender:Male
  • Location:Spain

Posted 03 September 2017 - 15:34

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

 

Spoiler

 

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 that transport: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):

VPDpro_v1.0.png

 


Edited by Raul (ulneiz), 03 September 2017 - 15:35.

:excl: Development of my tool: GT16-Colors

 

:excl: My API wishlist R3.1 (updated 24 July 2017):

Spoiler

 

:excl: My Renoise 3.1 wishlist (updated 18 July 2017):

Spoiler

#2 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1467 posts
  • Gender:Not Telling
  • Location:Sweden
  • Interests:music, philosophy, engineering

Posted 04 September 2017 - 10:21

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

 

EDIT: I noticed now that we've already dealt with this topic here http://forum.renoise...nt-is-possible/ 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 :)


Edited by joule, 04 September 2017 - 10:35.


#3 Renoised

Renoised

    Super Advanced Member

  • Normal Members
  • PipPipPipPip
  • 125 posts
  • Gender:Male

Posted 06 September 2017 - 00:09

Wow, Raul, this looks very interesting! :w00t:



#4 Raul (ulneiz)

Raul (ulneiz)

    Guruh Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPip
  • 965 posts
  • Gender:Male
  • Location:Spain

Posted 06 September 2017 - 09:57

@Joule. Hi & Thanks!  :)

 

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 live on 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.


:excl: Development of my tool: GT16-Colors

 

:excl: My API wishlist R3.1 (updated 24 July 2017):

Spoiler

 

:excl: My Renoise 3.1 wishlist (updated 18 July 2017):

Spoiler

#5 joule

joule

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1467 posts
  • Gender:Not Telling
  • Location:Sweden
  • Interests:music, philosophy, engineering

Posted 06 September 2017 - 10:14

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

 

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


Edited by joule, 06 September 2017 - 10:15.


#6 Raul (ulneiz)

Raul (ulneiz)

    Guruh Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPip
  • 965 posts
  • Gender:Male
  • Location:Spain

Posted 06 September 2017 - 10:54

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

 

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


:excl: Development of my tool: GT16-Colors

 

:excl: My API wishlist R3.1 (updated 24 July 2017):

Spoiler

 

:excl: My Renoise 3.1 wishlist (updated 18 July 2017):

Spoiler

#7 Renoised

Renoised

    Super Advanced Member

  • Normal Members
  • PipPipPipPip
  • 125 posts
  • Gender:Male

Posted 06 September 2017 - 14:33

@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 :P

Looks very cool B)



#8 Raul (ulneiz)

Raul (ulneiz)

    Guruh Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPip
  • 965 posts
  • Gender:Male
  • Location:Spain

Posted 06 September 2017 - 14:45

@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 :P

Looks very cool B)

 

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


:excl: Development of my tool: GT16-Colors

 

:excl: My API wishlist R3.1 (updated 24 July 2017):

Spoiler

 

:excl: My Renoise 3.1 wishlist (updated 18 July 2017):

Spoiler