Forums > Max For Live

Note glitches in midi sequencer

March 28, 2013 | 5:22 pm

Inspired by Sting! (from Skinnerbox) and fascinated by the Euclidean/Bjorklund algorithm I decided 3 weeks ago that its about time to dig into M4L. After a lot of frustration and even more excitment I ended up with my first own device. For most part it already does what it is supposed to do: creating odd midi patterns by twisting 8 knobs (I want to use it with the APC40) and I’m quite happy with it.

What is puzzling me now is that when I record the pattern, there are sometimes (couldn’t figure out yet when exactly) some really short like ghost notes triggered. There could be a few reasons for this: the way I handle duration, the sustain object (which is triggered if you set duration to 0), or the live.step object. Since I coudn’t nail down the troublemaker, I post here the whole patch.

Has anyone one of you an idea where the problem could lie? Also, if you see any optimization potential, I’d really appreciate your input. Some solutions I found look pretty messy to me (like the way the note stretching is handled by the sustain object) an every hint on how to polish the patch is welcome.

Made in Live 9.0.2 with Max 6.1.1 (wonder why copy compressed Shows max5_patcher).

I coudn’t attach the js file. Download it here http://cycling74.com/forums/topic.php?id=35589&bb_attachments=216981&bbat=5135 and make sure it’s named "bjorklund-1.js".

– Pasted Max Patch, click to expand. –

Credits got to
Skinnerbox (I learn a lot of there patch and copy/pasted some stuff)
All the guys working on the bjorklund script found here: http://cycling74.com/forums/topic.php?id=35589 (I used the one of cudnylon)


March 30, 2013 | 12:51 am

It gets really difficult to test these things, because we’d need to wrap it into a max for live device, save your js and make the whole thing work like that, just to help you.
Another solution is to simply freeze the device, that way we can get the actual device with its dependencies…

> there are sometimes

uh oh. This is the worst, since basically we don’t even know how to reproduce the problem then.

>There could be a few reasons for this: the way I handle duration, the sustain object (which is triggered if you set duration to 0), or the live.step object.

well, those are three possibilities, each of which can be removed from the patch before a testing session.

have you tried running a [print] stream off the duration values? It seems like you’re attempting to filter out the value 7.5, so I’m guessing you already have some messes coming from there?


March 30, 2013 | 8:01 am

I understand that I should have taken more time to investigate, it’s just that I got impatient because my Push arrived that day and I tried to end this project using the sledgehammer :-) Thanks for taking the time nonetheless!

I’ll get back to this as soon as I could break down the problem to a question which doesn’t require a lot of time to investigate.


Viewing 3 posts - 1 through 3 (of 3 total)