how about using the renoise.song().transport.playback_pos
to be able to jump and glide around inside a pattern based on certain values set from a midi knob.
could possibly set it so if the midi knob was 0 the pattern would play normally, if the midi knob was -1 to -10 it would go back 1 increment, -11 to 20 back 2 increments so forth. 1 to 10 go forward 1 increment, 11 to 20 forward 2 so forth.
Increment being a setting of another knob, from 1 line to 1/2 pattern.
increment type knob for setting type of increments (log, lin, exp, computer math (1,2,4,8,16,32,64,128,*))
so if you had the play knob set at -5 with increment knob set at 1 line, it would continually play that 1 line. change the increment type knob to computer math, and get synced numbers, switch to log and get un-synced numbers.
I’m uncertain how autoseek would respond to this, I can only imagine it would sound very much like the sample offset command. Which is good. As this is simply an idea for a way to create a macro or pattern side version of 09XX.
What I don’t know is if it’s possible to go deeper than one line with the renoise.song().transport.playback_pos
I sort of get that you want…
Constrain playback to a pattern.
A midi knob to control position in that pattern,.
A second midi knob to control the size of the playback slice; like Block Loop but finer control.
Is this right? No offence, but it’s a bit incoherent.
I understood it pretty well except for the interpolation part, but yeah Conner, I’m pretty sure it’s exactly what you said. Allowing to skip around a pattern using a knob that tells which direction, and a knob to set the size of the skips. I think it’s brilliant. Would make for amazing live capabilities. What would be even better is if someone could somehow create a script that made it possible to set different positions in the pattern to actual MIDI notes, so I could jump around the pattern by jamming on my MIDI keys, and better yet, the pattern positions set work on whatever pattern is currently playing, so I could loop the current pattern, jam on my keys a bit, then turn off the loop and let it play into the next one and do the same thing. Just a thought.
Did any of you guys try the Navigator? Does almost exactly this thing, although it’s button-based instead of dial-based.
Also: if anyone is starting to write a new tool for this purpose, beware that the block-loop has many limitations that you need to work around - check out the Navigator source code, or read this for a quick summary of the issues I’ve encountered.
Yeh, pretty much that, I was really tired when I wrote it. I’ve been thinking about it for a few months, and originally wanted to do this with OSC so it could be used on multiple instances of renoise and not localized to one instance and controller. I realized I can’t do it.
The core idea is just like Lawrence Davies Insta-Jungle, except instead of samples in a buffer, it would be directly using pattern data.
Not locking the pattern, only using the current pattern length for maths, so can move from one pattern to the next, forward/backward.
first 3 knobs
-Play knob, position movement directional jump forward/back.
-length/increment knob, for adjusting area of pattern.
-type knob, increment length adjustment type(synced/non-synced).
I’m not really sure how to do it but, there needs to be a way of moving through the pattern while repeating based on LPB and BPM.
Might need more knobs.
-directional knob, for direction of repeat. (forward or backward) auto-seek is perfect for this I think.
-repeat # knob, for how many repeats of each incremental area.
It would be similar to the pattern break command and sample offset command combined into an onTheFly? completely pattern data based context.
Using MIDI for it is great too, as it then allows easy internal control from meta-devices and automation if one was inclined to do so.
Is it possible to get into the subtick area (where pattern line delay is) with renoise.song().transport.playback_pos?
This might look better as a flow chart as all of those knobs/parameters are in one way or another connected to each other.
I think it makes sense since the playback_pos will always be moving in the same direction. What would be happening here is just telling the playback_pos to back up or jump forward in zero time so I don’t think it would fail autoseek if it was enabled.