Hello Chris,

The Launchpad has two buffers for the leds, of which one buffer is shown at any time. I've seen glitches when changing mode to. My guess is that the second buffer is shown at that time.

I tried to load your code, but the bpatchers appear to be empty and the patchcables to them cannot be connected. It's better to freeze the device and upload the whole .amxd file when you post it.

Please let us know when and where you publish your device!

Kind regards,

Willem.

Thanks Willem, I'm still relatively new to sharing patches, but I've frozen the file and attached it as an amxd. Your idea about the buffers seems to ring true in my head, I tried to use the send off messages to all the leds in the buton_matrix when the mode changed, but the obvious I'm guessing it would need to be before the mode changed to be effective.

Chris

Okay, So, I've added to the lauchpad seq 2 external a gate controlled by an m4l.api.validid linked to the button matrix path. This seems to work about 80% of the time when switching to session mode, but not at all when switching to user1 or mixer mode. To be honest, this is about good enough for me, the option of switching buffers is there, but I can't find a way of achieving it through the API, and as I've relied on the API for the whole patch thus far, to implement double buffering would imply that I'd need to rewrite most of the patch.

If you disconnect the midi output when you're not in the User mode 2, your problem will be solved.

Hi Chris,

The problem is that your device keeps sending led-information to the Launchpad, even when the mode is changed. I have published a Launchapad interface at http://www.maxforlive.com/library/device.php?id=298 which signals the changing of modes and has a buffer to remember which leds are on in user2 mode. When not in user2 mode this device will not send updates to the leds.

This device sports 8 running lights. I noticed that the display of the pitch dials did not update when the sequencer is running. I'm afraid this is caused by the terrible slow MIDI interface of the Launchpad. Last weekend I found out that the leds at the top row can only be updated using the 'Rapid LED update'. But these led's are at the end of the 120 byte MIDI cyclus. This means every update will take about 100 milliseconds. Could it be that every led update is using this so called 'rapid' update when using Live API? At the moment I'm trying to bypass Live API altogether, using a MAX java external as an interface. I'll keep you informed on this forum of my results.

Best regards,

Willem.

Hi Willem, Okay, I get that it is still sending messages to the launchpad after mode-change, so to reflect that I've added a gate controlled by the launchpad live.text, which seems to work more reliably. However, the problem still persists when changing to user1 or mixer mode, why, I cannot understand. I'm not quite sure what you mean about the pitchwheels, they seem to me to function perfectly.

Thanks

Chris

Hello Chris,

I'm on a Windows XP machine, quad core 2.4 Ghz. Should be fast, right? Wrong!

When I'm running your device or my own Rainstorm sequencer conversion (it's published here first!) there's to much MIDI to be sent to the Launchpad. All MIDI is sent nicely, but the pace is lagging behind.

The screen update appeares to be lagging behind when there's too much MIDI sent to the Launchpad (at least on my machine). I think you're running into the same problem, for which I have no solution yet.

Willem.

the code in novations beta launchpad seq and in monomeemu by soundflower are invaluable in getting complex devices to talk to and from live - look at the parts on changing modes monomeemu - http://www.maxforlive.com/library/device.php?id=141

heres an older version of monomeemu - shares a lot of code with novations beta seq - the new version of it is quite different