Project
work in progress: experimental onclock sequencer
Started by electrofux on .
Sign in or create an account to join the conversation.
This one is inspired by:
http://www.youtube.com/watch?v=uV9-XA5MPwY
It is still a work in progress and has some functions not working and probably some bugs. So use at you own risk
It doesnt use any of the sequencer objects but instead an onclock script to drive the sequencer.
On the left are 3 pages selectable "Triggers", Pitch and Velo.
Triggers defines what the sequencer does with a step. There are selectors below the faders and they interact with the faders.
The faders tell the sequencer how many pulses it has to count down before going to the next step.
And the selecter tells the sequencer what to do with a pulse:
"x..." do one trigger and the count down the rest
"xxxx" do as many triggers as there are Counts
"x---" do a triger and hold the note for the rest of the counts
"." do nothing
On the Pitch Page you set the pitch with the faders and the octaves with the selector
Velo is setting the velocities
The Range fader sets the first and last step.
In the Direction Selector there is a bug with Random, when you set random and then pendulum the step stalls at the last step. Hit reset <| to reset the step.
On the bottom left is an all notes off button.
Ah, i forgot currently only 1/16th division works until i have fixed everything that comes up.
Sadly it will never get as cool as the original because there is no gatelength setting possible with an onclock sequencer, as well as no swing.
The best results you get when you tweak the Env of the Synths.
For those who look inside. There is more stuff down the container. Actually the main Sequencer. I just redid the controls and took the easy way as the faders just control the multisliders. Have to rework that as it leads to the faders sometimes not show the actual values.
ExperimentalSequencerbeta05.jzml
http://www.youtube.com/watch?v=uV9-XA5MPwY
It is still a work in progress and has some functions not working and probably some bugs. So use at you own risk
It doesnt use any of the sequencer objects but instead an onclock script to drive the sequencer.
On the left are 3 pages selectable "Triggers", Pitch and Velo.
Triggers defines what the sequencer does with a step. There are selectors below the faders and they interact with the faders.
The faders tell the sequencer how many pulses it has to count down before going to the next step.
And the selecter tells the sequencer what to do with a pulse:
"x..." do one trigger and the count down the rest
"xxxx" do as many triggers as there are Counts
"x---" do a triger and hold the note for the rest of the counts
"." do nothing
On the Pitch Page you set the pitch with the faders and the octaves with the selector
Velo is setting the velocities
The Range fader sets the first and last step.
In the Direction Selector there is a bug with Random, when you set random and then pendulum the step stalls at the last step. Hit reset <| to reset the step.
On the bottom left is an all notes off button.
Ah, i forgot currently only 1/16th division works until i have fixed everything that comes up.
Sadly it will never get as cool as the original because there is no gatelength setting possible with an onclock sequencer, as well as no swing.
The best results you get when you tweak the Env of the Synths.
For those who look inside. There is more stuff down the container. Actually the main Sequencer. I just redid the controls and took the easy way as the faders just control the multisliders. Have to rework that as it leads to the faders sometimes not show the actual values.
ExperimentalSequencerbeta05.jzml
This one seems interesting! The man traveled to China to find 8 way switches.. wow. : )
I like how you have made it nicely compact, I could see it being a drop-in module for other templates.
What do you mean about gate length not being an option? Isn't there some way to control gate voltages via a controller, like on the MIDIbox CV/CV2?
Anyways, cool, keep us posted on the dev! I think I saw one switch in there that had an error in it..
I like how you have made it nicely compact, I could see it being a drop-in module for other templates.
What do you mean about gate length not being an option? Isn't there some way to control gate voltages via a controller, like on the MIDIbox CV/CV2?
Anyways, cool, keep us posted on the dev! I think I saw one switch in there that had an error in it..
Yeah, it is meant to fit in my Reason template eventually.analog604 wrote:This one seems interesting! The man traveled to China to find 8 way switches.. wow. : )
I like how you have made it nicely compact, I could see it being a drop-in module for other templates.
What do you mean about gate length not being an option? Isn't there some way to control gate voltages via a controller, like on the MIDIbox CV/CV2?
Anyways, cool, keep us posted on the dev! I think I saw one switch in there that had an error in it..
The Problem with the gate length in script driven sequencers is, that you have only the clock pulses on which you can trigger the noteoff and thus make notes shorter or longer. And 1/64th is the shortest clockpulse. I have tried to run the sequencer with 1/64th division and do triggers on every 4th pulse so i get a 1/16 division and also have another 3 pulses to set the noteoff. But when i do this the sequencer starts to drift. So i have ditched this.
But that brings another problem because in order to have all the divisions going i need an onclock script for every division there is. Thats why currently only 1/16th are going.
The error script comes from an older version were it was 16 steps and had a switch for the stepcount. But i figured that i dont need this when i already have a range slider to set the first and last step. Also 8 steps like in the Metropolis are way enough for this type of sequencer. Have to delete some stuff besides of that script. I also think that a total pulse count monitor would be a good thing so you can easily see how long the sequence is in the end. And some pattern saving pads of cours. with this it should be easier to switch patterns, even quantized or chained since it doesnt have the step attribute.
From my own experience I know about these clock/division problems.
The way I've tried to maximize performance is to uncheck every object/variable/control that does not need to be checked,
try to limit the number of Monitor objects, because from what I understand, Lemur will try to evaluate the checked objects on every frame.
Limit the onFrame scripts to one and do not declare variables within on_clock or on_frame scripts (I see that you haven't in the 2 onFrames, Plus & Minus). The code in these needs to be as sparse as possible.
Recently, I've been attempting to reduce the number of objects in general by using canvas to write text and do interface design, but that is difficult and causes a new set of problems.
I can't see running an onclock for every division that there is.
That might not be practical and cause more performance problems, if the scripts are actually run on mark, then there will at times be a cascade of them running 1/64 runs every 1/32, 1/16.. and so on.. and 1/16 runs on every 1/8..1/4.. 1..
What I've been experimenting with is to use one 1/64 onClock script and use clock divider counters, as you tried with the 4th pulse for a 1/16th, how far this drifts.. I don't know, because I'm doing this in large template with parallel sequencers and I reckon it could be awhile to run smoothly in the land of scripting, as in requires faster hardware, and perhaps Lemur app performance improvements.
Doesn't stop me from trying out new methods though, in the hope that one day it can be perfected.
cheers
Jay
The way I've tried to maximize performance is to uncheck every object/variable/control that does not need to be checked,
try to limit the number of Monitor objects, because from what I understand, Lemur will try to evaluate the checked objects on every frame.
Limit the onFrame scripts to one and do not declare variables within on_clock or on_frame scripts (I see that you haven't in the 2 onFrames, Plus & Minus). The code in these needs to be as sparse as possible.
Recently, I've been attempting to reduce the number of objects in general by using canvas to write text and do interface design, but that is difficult and causes a new set of problems.
I can't see running an onclock for every division that there is.
That might not be practical and cause more performance problems, if the scripts are actually run on mark, then there will at times be a cascade of them running 1/64 runs every 1/32, 1/16.. and so on.. and 1/16 runs on every 1/8..1/4.. 1..
What I've been experimenting with is to use one 1/64 onClock script and use clock divider counters, as you tried with the 4th pulse for a 1/16th, how far this drifts.. I don't know, because I'm doing this in large template with parallel sequencers and I reckon it could be awhile to run smoothly in the land of scripting, as in requires faster hardware, and perhaps Lemur app performance improvements.
Doesn't stop me from trying out new methods though, in the hope that one day it can be perfected.
cheers
Jay
Thx for the tips regarding performance. Gonna work over the template and untick most of the stuff.
The problems with the sequencer drift when using your own division counters on 1/64th script were pretty strong. I made a very simple script and let it run against a normal sequencer and from loop to loop it was more and more lagging behind or even ahead (in case of higher division like 32th,64th). I wasnt able to sync this and reported it already (https://forum.liine.net/viewtopic.php?f=32&t=4093). What i wanted to do is an onclock for every division and make it return if it doesnt match a division set switch. It worked for two divisions, havnt tried for that many though.
But i am glad that atm the two templates i did sync up in an acceptable way with Reason and are a lot of fun to use (especially the experimental one). There is always room for improvement though
The problems with the sequencer drift when using your own division counters on 1/64th script were pretty strong. I made a very simple script and let it run against a normal sequencer and from loop to loop it was more and more lagging behind or even ahead (in case of higher division like 32th,64th). I wasnt able to sync this and reported it already (https://forum.liine.net/viewtopic.php?f=32&t=4093). What i wanted to do is an onclock for every division and make it return if it doesnt match a division set switch. It worked for two divisions, havnt tried for that many though.
But i am glad that atm the two templates i did sync up in an acceptable way with Reason and are a lot of fun to use (especially the experimental one). There is always room for improvement though
Which iOS devices are you using for the testing?
So far i have tested with Thor and Nave while being synced to Funkbox, which is the only drum machine i was able to sync up to correctly.
But my main focus is on making it run synced to and as an input to Reason which works ok so far.
But my main focus is on making it run synced to and as an input to Reason which works ok so far.
Well, it is pretty fun to play around with but when it comes to syncing it to a PC it is not going so well. I seem to be not able to get the timing tight on this one.
Dunno probably there is too much in the on clock script that makes it shaky.
I have attached the latest version. But as i said the timing is not reall tight. Maybe on an Ipad5.
It would be interesting to know if it runs better on an newer Ipad. Let me know.
experimentalsequencerbeta2.jzml
Dunno probably there is too much in the on clock script that makes it shaky.
I have attached the latest version. But as i said the timing is not reall tight. Maybe on an Ipad5.
It would be interesting to know if it runs better on an newer Ipad. Let me know.
experimentalsequencerbeta2.jzml
It would be cool if someone could check the on clock script that is driving the sequencer.
It sits in the Switches Object and is called runtest4().
I know there is alot of stuff in there. But in case the sequencer is set to normal forward runmode and doesnt use any of the triggermodes (all sliders down) then all the script does is checking 2 if thens before outputting a note/noteoff. Still i cant get it to run in a tight way. It seems to have its own rythm.
The first if (if stepinc==1) is only there for later use in case i want to create different timedivisions but i have set it to 1 for the time being.
The second checks what type of Trigger the step is doing depending on the switches below the trigger sliders.
The third if chounts the pulses per step (if there are any to make) or sets the next step according to the runmode (forward, backward etc.).
the fourth one sets the runninglight.
It sits in the Switches Object and is called runtest4().
I know there is alot of stuff in there. But in case the sequencer is set to normal forward runmode and doesnt use any of the triggermodes (all sliders down) then all the script does is checking 2 if thens before outputting a note/noteoff. Still i cant get it to run in a tight way. It seems to have its own rythm.
The first if (if stepinc==1) is only there for later use in case i want to create different timedivisions but i have set it to 1 for the time being.
The second checks what type of Trigger the step is doing depending on the switches below the trigger sliders.
The third if chounts the pulses per step (if there are any to make) or sets the next step according to the runmode (forward, backward etc.).
the fourth one sets the runninglight.
electrofux wrote:Well, it is pretty fun to play around with but when it comes to syncing it to a PC it is not going so well. I seem to be not able to get the timing tight on this one.
Dunno probably there is too much in the on clock script that makes it shaky.
I have attached the latest version. But as i said the timing is not reall tight. Maybe on an Ipad5.
It would be interesting to know if it runs better on an newer Ipad. Let me know.
Are you connecting over Wi-Fi or with a hardware MIDI adapter?
I am not using WIFI. I have made test with Lemur slaved to the iconnect midi and one where Lemur runs with internal sync triggering either Thor or Funkbox on the ipad or Reason. The best reslut was when it was slaved to Reason. But you can hear a clear difference between a normal StepNote object triggering a 16th note sequence and my onclock sequencer doing the same.nick_liine wrote:electrofux wrote:Well, it is pretty fun to play around with but when it comes to syncing it to a PC it is not going so well. I seem to be not able to get the timing tight on this one.
Dunno probably there is too much in the on clock script that makes it shaky.
I have attached the latest version. But as i said the timing is not reall tight. Maybe on an Ipad5.
It would be interesting to know if it runs better on an newer Ipad. Let me know.
Are you connecting over Wi-Fi or with a hardware MIDI adapter?
I've noticed a very good increase of Lemur template (scripting) performance in general between the iPad3 and the latest gen, iPad Air (A7 SoC ?).
On a multi-slider object converted to canvas code scripting, the 'sliders' were slow to recognize touch and change on the iPad3, but on the Air, they are instantaneous, and my step position pointer (on new LModIt lite) moves smoother across multiple matrix/tracks.
I'll load your template up and see how it runs on the Air.. I don't have Reason, but will point it at another softsynth. I've only had the thing for a few weeks now, and haven't run too many actual studio tests.
Jay
On a multi-slider object converted to canvas code scripting, the 'sliders' were slow to recognize touch and change on the iPad3, but on the Air, they are instantaneous, and my step position pointer (on new LModIt lite) moves smoother across multiple matrix/tracks.
I'll load your template up and see how it runs on the Air.. I don't have Reason, but will point it at another softsynth. I've only had the thing for a few weeks now, and haven't run too many actual studio tests.
Jay
That would be nice to know. Doesnt matter if it is Reason or anything else.analog604 wrote:
I'll load your template up and see how it runs on the Air.. I don't have Reason, but will point it at another softsynth. I've only had the thing for a few weeks now, and haven't run too many actual studio tests.
Jay
Still have to sort this out, I am unable to locate my iRig midi i/f. 
Also had to order a 'Lightning' adapter for it.
I did run it over wifi to Live, template external sync to Live. It was fun to mess with, but when I brought in the drums sequenced by Live, things were too far off time. So I changed the offset and MIDI timing on Live, close, but could not get a solid beat sync, kind of expected with Wifi.
Still, having recorded the MIDI sequences that your template produced, I quantized the loop to 16ths and got it all usable in a nice little new track!
Also had to order a 'Lightning' adapter for it.
I did run it over wifi to Live, template external sync to Live. It was fun to mess with, but when I brought in the drums sequenced by Live, things were too far off time. So I changed the offset and MIDI timing on Live, close, but could not get a solid beat sync, kind of expected with Wifi.
Still, having recorded the MIDI sequences that your template produced, I quantized the loop to 16ths and got it all usable in a nice little new track!
Ah, wrong post.
I'm still waiting for the parts to arrive to get the direct midi running again. Got the lightning 30pin connector, waiting on an iConnectMIDI2+ to arrive. The iRig with two (kind of short) wires coming out of my older iPad created a big mess anyways.
I like the iconnect a lot more over the irig. But prepare for some set up action. Without setting up the iconnect software properly this doesnt work so good out of the box.
Thanks for the heads up, I've just got around to plugging it in.
electrofux wrote:I like the iconnect a lot more over the irig. But prepare for some set up action. Without setting up the iconnect software properly this doesnt work so good out of the box.
Any tips on setting up the iconnectmidi from someone with a little experience would be greatly appreciated!
Do you mean to suggest that the default setup of the iconfig ports is best adjusted first to maximise performance?
Im hoping that is the case - it might help with the occasional "missed note/unintentional stutter effect" that im getting when syncing up to the PC.
The setup of the iconnectmidi4 is honestly quite bewildering, flexible no doubt - but not self explanaitory
Ok I have discovered one thing with the Iconfig app - make sure your not setting your ports to send midi back to themselves. This can lead to major issues and clocks running at 1/2 or 2x, and was happening with the default setup in Iconfig!
Im still experiencing some skips or stutters with the drum sequencer though...
Do you mean to suggest that the default setup of the iconfig ports is best adjusted first to maximise performance?
Im hoping that is the case - it might help with the occasional "missed note/unintentional stutter effect" that im getting when syncing up to the PC.
The setup of the iconnectmidi4 is honestly quite bewildering, flexible no doubt - but not self explanaitory
Ok I have discovered one thing with the Iconfig app - make sure your not setting your ports to send midi back to themselves. This can lead to major issues and clocks running at 1/2 or 2x, and was happening with the default setup in Iconfig!
Im still experiencing some skips or stutters with the drum sequencer though...
I'm wondering if this is much easier with the new Lemur version.
Sb. made some Sequencers yet?
Especially for eurorack...
a Lemur Version of Dark Time would be amazing
Sb. made some Sequencers yet?
Especially for eurorack...
a Lemur Version of Dark Time would be amazing