Possible to switch pattern without resetting position

[James_Britt (James Britt / Neurogami)]

@kazakore

Plus I must have been tired as even though I read you post I then said I didn’t know how you were setting your pos.sequence value. I’ll put it in context where I would in your example code instead then.

  
  
 local rns = renoise.song   
 add_global_action {   
 pattern = "/pattern/into",   
 description = "Jump to the given pattern number but keep same relative line position",  
  
 arguments = { argument("pattern_index", "number"), },  
  
 handler = function(pattern_index)  
 if pos.sequence > #rns().sequencer.pattern_sequence then app.show_status("Sequencer number outside of range!") return end  
 local pos = renoise.song().transport.playback_pos  
 pos.sequence = pattern_index  
 rns().transport.playback_pos = pos  
 end  
  

You have extra code there you know instantly can be skipped if you value is out of range. Still very minor on the grand scheme of things! (I assumed the print (“Jump into!”) is a hangover from testing stage, to make sure it really fired, so I have removed that too.) Plus I moved the rns variable to outside of the function as personally I use it all over my code to say that little bit of typing… Maybe it can’t really go there for the OSC stuff? I’ve not done anything with that side of things so sorry if I should have moved it.

I copied the code from a snippet earlier in the thread. I have been using print calls to check that the handlers are actually getting hit. Once I’m confident that is happening I take it out.

Thanks for pointing out the bit about renoise.song; that’s already available throughout the GlobalOscActions.lua file so there’s no need to re-fetch it.

As for testing the validity of the pos value, it comes down to which is more efficient: the occasional execution of code that is going to fail, or the (more frequent) execution of a value test. In actual practice I expect to have a controller device (XBox Kinect or a Leap Motion) whose program is going to limit the possible values it sends as part of the OSC message. For me, if an unusable value is gets sent that’s a bug in the client code, not in the server code. However, I’ve done no benchmarks so the overhead of that value check may be so minuscule that it makes no perceivable difference in execution speed. One thing I don’t want is for the song to stop, skip, or for the user to be otherwise interrupted.

I’m pretty new to Lua, but so far it seems that by default it does not blow up for certain kinds of errors; you have to manually check for error flags and take deliberate action. This seems reasonable for software that is running inside something else, and if this is a deliberate aspect of the language I’m comfortable exploiting it to reduce lines of code.

It’s a mixed blessing though. Using exceptions for flow control is frowned upon by many but I’m more interested in shorter code that does what I want.

[kazakore]

@Neurogami

As for testing the validity of the pos value, it comes down to which is more efficient: the occasional execution of code that is going to fail, or the (more frequent) execution of a value test. -snip- I’ve done no benchmarks so the overhead of that value check may be so minuscule that it makes no perceivable difference in execution speed.

I 100% expect this to be the case in such simple code as this or anything I have ever written! More my reason for starting to include it it so that you have some feedback when you press something and nothing happens when you think it should do. The message popping up in Renoise’s status bar is in some ways more important that the Return command to stop processing the rest of the code. It also gives you an instant idea of which part of the code to look at should it start happening when it probably couldn’t, as you can search the code for the error message you used.

The LUA commands seem to get run amazing fast at times!