internal Clock seperation of objects

So, Im trying to have two sets of a StepNote, StepSlider and StepSwitch run on two clocks - one set to clock0 and one set to clock1.

A bag of bugs has been opened.

Here's the testing example:
clocks-wtf.jzml

Even this

setattribute(StepNote0,'clock', 0);
setattribute(StepSwitch0,'clock', 0);
setattribute(StepSlider0,'clock', 0);
setattribute(StepNote1,'clock', 1);
setattribute(StepSwitch1,'clock', 1);
setattribute(StepSlider1,'clock', 1);

Doesnt change the clock setting for StepNote1 object

It's fkin annoying this and the rest of the little bugs, this one though renders the sequence and clock useless, try reversing
The sequence by setting a negative bpm, see how long it runs before crashing.

wow, really? I wanted to go throught those 'new' objects and build something with them, but as it seems it won't be worth the effort.

Try the included mono sequencer, select 4 say kicks , then with the previous pitch slider, select say a snare without selecting it on the step note, Then increase the bpm . The snare starts sounding randomly, try increasing the divider parameter ..... All snare no kick. You can even make 2 pitch steps previous sound, at the extreme . So when you add more objects to the template the bpm at which this shit happens comes down to not much above 120. So the clocks accuracy ain't independent Useless.
I just spent days emulating the probability aspect of the social entropy midi engine . I needn't have bothered, I already had it.

EDIT - I didn't see the date of the original post.... nevermind


I noticed you had StepSwitch0 set to use Clock1 instead of Clock0. Also (I haven't played much with these objects) some had Plays Free box checked and others didn't. When I unchecked them all and set StepSwitch to Clock 0, everything ran as designed (on the computer). I was not attempting to control any sounds, so the timing from an iPad was not tested.

FWIW, the Lemur frame model didn't seem to lend itself to realtime, tight timing like what is needed for a sequencer. The fact they retrofitted a clocking model in/on top of it still makes me suspect that timing can always be an issue.

Again and again, I call out to the Lemur developers to give us a detailed explanation of what Lemur is doing to run our templates. An explanation of the frame approach along with details on what happens at the end of a frame, what happens onload(), etc would be extremely useful in creating professional applications. Kind of like Liine's version of the old Inside Mac manuals.

Hi guys,

When you do find bugs, please send a brief description (ideally with JZML example) to support [at] liine.net

Cheers,
Nicolas