Organization of Modes populating Launchpad LEDs

Hello

I am starting to get frustrated from my lack of experience in simply organizing large amounts of LED light on/off messages.

I am writing a launchpad program that switches between different modes, each with different color displays, also displays that are drawn from DAW feedback, I am starting to get confused. I am so frustrated trying to figure out what I did that I want to start over with a simpler/easier method for turning lights on and off between modes. Something that's easy to add on to.

Right now I'm basically writing each separate functioning "mode" into a different preset, and using the "activate/deactivate preset by name" functions to start mode specific timers living inside each other modes' preset. So after my start up preset is done, I am in my first mode "main sequencer mode". As soon as I enter this mode, an "on preset activation" triggers a "main sequencer light timer" that holds it's selection of lights on until I leave "main sequencer mode". When I "preset deactivated" (exit) main sequencer mode, I then do a "main sequencer mode lights off" message before I switch presets to "block mode". Where the same thing happens with a "preset activated--->blockmodelighttimer" . The problem I am running into now is that I am trying to add a toggling "instrument selection mode" and I am trying to put lights over the certain rows of the 8 different "block mode" light displays, depending on if I press a side button, the row would cycle through different colors. I tried to give each row and each button controlling the row a unique global variable, then factor those global variables into the rules/note o messages of my "main sequencer/block mode" light messages, but I apparently have something screwed up. I can't even make sense of the LED display to diagnose what I screwed up haha!
So I'm thinking before I go much further that I take a step back, ask for help, replan my lighting control, and start fresh.

Do you make presets just for "lights on" and "lights off"?
Do you give every LED a global variable?
Do you just organize a bunch of translators hard-wired to the pad #'s?
Do you guys have any suggestions or techniques that help you stay organized with lots of LED action?\

Thanks

Can you please export your MTP file and post the code here so we can see where you're at and what we can to do to help make it function for you?

ibanman555 wrote: function?

Ummmm I wish I could now but I basically gutted it to start over. I will post my next draft here when it's done though. Hopefully before the week is over.

Thanks for the reply

ibanman555 wrote:Can you please export your MTP file and post the code here so we can see where you're at and what we can to do to help make it function for you?

Ok here is the most recent version.
I have smoothed out most of the original bugs.
But now I have a whole host of other things to figure out.

I have disabled the "open project" preset for your comfort haha, otherwise when you open the file it will start clicking on your screen and pressing buttons.
This version is totally automated, from the moment I click on the Bome icon it opens up Reason which loads a template I made just for this. Then closes the MIDI device error message (always happens with bome) , focuses the sequencer window and closes the browser window, then starts playing the transport. (timed mouseclicks/physical keys) I have one hidden track in my Reason sequencer with all different variations of note lengths penciled in to it then being routed out of Reason into BMT so I have the ability to use session BPM time signiature subdivisions to trigger anything as an option.


I mapped every button and knob on the launchpad mk2 to global variables. To hopefully always edit them there. But I have already gotten sloppy with the record arm channels variable definitions which live in their preset. Working fine, but needs to be made consistent eventually.

There's a press any key thing at the beginning that helps me see if the midi inputs of the orbits are set up right. (2 of them)
I also use it for a little house keeping and making sure the startup stuff is seperate from the main program stuff.

Main sequencer mode is basically there! It's absolutely amazing, depending on which top button I choose, it activates that color (both in reasons block mode and on the launchpad) to be lit up when I press the pads; this simultaneously "pencils" in the selected block color across bars on the sequencer giving me 64 - 8 bar sections that can be filled with the contents of whatever block I pencil into it. There are 8 different blocks, with 8 different colors. I now face the next challenge with this one. Memory. When I switch back and fourth between block mode and main sequencer mode, the pads don't stay true to what I did on them before changing modes, the sequencer is the same obviously. I understand that this is because the lighting message is just a static "lights on" message I send upon opening the mode. What I don't understand is how to go about structuring the assignment of variables to the pads to create a color memory that stays updated when changing between block and main sequencer mode.

I disabled my Bome drawn scanner/playhead because I could not figure out how to do it, and I know how to do the same thing very easily drawing notes on the sequencer in Reason, and sending them MIDI out straight to the launchpad.

Instrument mode is only setup to change colors cycling between 5 different colors in this version. Right now it is triggered by the up and down arrows on the guitar wing. I am hopefully going to make some progress getting actual instruments into these babies today.


Anyway check it out let me know if you have suggestions or ideas.

Thanks