cyberboy666
commented
4 years ago hii @TubularCorpration ! and thanks for the detailed description / idea - i agree this would be a super useful way to enhance the "performance" aspect of this instrument (which is something i think about often)
when i first implemented midi i did try to also read the midi clock. one problem i found then was the clock is pretty fast and the python thread reading this is not super optimised , so i found it was flooding the message queue a bit and dropping some actual messages. (thats not to say it cant be done , just that would need to rethink this part a bit / play around to get it working)
for the main sampler engine (playing back video files) the shortest loop possible is around 2 seconds , which amounts to a lot of midi ticks (~23 000) -> in my experiments, since triggering video files works better with longer cycles like bars rather than notes, i found that using a midi sequencer to send a SWITCH (->) command every bar / every four bars was a better way to synchronise
still i agree with you that having this kind of clock control would be rad - it is noted, and will take a look when im working on a new version (not sure when that will be though)
finally, selecting the start / end subloop points with midi-cc is possible (and pretty trivial to implement) ; the only problem is that setting a new loop point triggers a video reload (actually only a new start point needs this) , so it would be better with some kind of scroll then accept interface (like a push encoder style) otherwise it will be constantly reloading a video on every value as you scroll over the timings with cc - ya know ?
TubularCorpration
doctea
I think a really useful feature would be the ability to receive MIDI clock and set the start and end time to a user definable grid when the corresponding key on the keypad (or equivalent MIDI message) is received. It would make it a lot easier (possible) to match loop lengths to music.
It would probably be good to also add a clock reset command to make it easy to fix sync issues that could happen if, say, Recur needed to be reset in a live situation - send the MIDI message bound to clock reset on the downbeat of a bar from your clock source and you'd be back in proper sync.
The basic idea being that you could set an arbitrary number of quarter notes (or ticks) and any loop start r end commands would be quantized to the NEXT CYCLE of that length. So for example, setting a quantize length of 4 quarter notes/96 ticks wouldn't mean that the loop start would be set 96 ticks from the moment the button was pressed (the way some step sequencers handle event quantization), but rather there would be an internal counter that would start when r_e_c_u_r received its first clock message, and could be reset to 0 by a MIDI start message or any message bound to clock reset in the midi map file, and would reset every N tics, where N was the quantize value set by the user, the way quantizing to a grid in most piano roll sequencers.
Also, it would be really useful to be able to use MIDI CC to set the start and end points to arbitrary locations in the current clip. Nothing complex, just (number of frames/128)*CC value, so a CC value of 0 would be the first frame, 64 would be the halfway point, etc.
Those two features would make it possible to integrate r_e_c_u_r into live music performance a lot more than you already can, without adding much complexity at all.
Unless it's already possible to do some or all of this and it isn't in the documentation yet. I know it's possible to continuously adjust the start and end points in detour but that's all I could find. One of the reasons it would be great to be able to do this in sampler (even if it's not as seamless as Detour) is that you could quickly select musically meaningful ranges out of a large file, and also because sampler has audio playback so it would be useful for integrating the audio from video files into the music.