![]() ![]() Prev track when on the first track in a bank will send prev bank, and select the last track in the bank. If you track switch to the next track and you are currently on the last track, it automatically sends a next bank, and selects the first track in the bank. Similar logic is already implemented now when track switching. The problem there is that changing banks manually would trigger it to start searching for the bank with a track in it, so to override that I’m thinking that banking to previous bank might just default to selecting the last track in the bank, and banking to next bank could select the first track in the bank. On the old one I locked away banking from the controller, but I am considering allowing for that now, but maybe with an option. ![]() The auto-banking logic is a bit tricky, so I’ve been working on making it a bit more abstract so it’ll be less keeping track of numbers and weird sysex (hopefully). ![]() I can’t really say any estimate on when I’ll be done, as my coding time is very limited. Maybe python 2 problems since it is now deprecated…Īnyway, I’ve been struggling to make time on my end, but trying to get a few minutes of coding and testing in on the mornings now on the next version of this, and it’ll happen.įor anyone interested in potentially trying it when it’s “done enough” I can infor that you’ll likely need to update to python 3.10 or later, and it’ll still need mido as well as rtmidi modules to run. I’m curious, what actually stopped working? I’m hoping there wont be more configuration than naming your midi devices. Unfortunately this is really an ‘as is’ solution, but I’m thinking this version will be significantly easier to work with and setup. The names will come after working out a better way to autobank, and I am hopefully going to be done with that this coming week. Rough idea right now is to figure out if a track change is performed, and then switch modes to get a long name, and then switch back to the ‘normal’ mode again. I already made some functions for conveniently setting names making use of both rows, but I need to work out how to override the original mackie behaviour in a way where it all works without glitches. It’s a bit tricky to figure out how to do this in the best way. This thread opened up for some ideas regarding this: Creative thinking needed (?), retrieve track names from Cubase to MIDI or OSC - #22 by Shorīasically making use of the MCU commands to go into eq, channel strip, aux send modes you will get a longer track name, so I am thinking about making use of this to read out track names. Ideally I want to omit the need to work with a max number of skips to attempt, and have it automatically work it out.Īt this point I should add that I am mainly targeting a single fader controller (I am using the Behringer X-Touch One), and as I don’t have a mackie controller with 8 faders, I don’t have any way to test how the following things will behave on those.Ī thing I’m working on is setting a nicer track name on the display, as well as opening up for using 2 rows of the LCD to display longer names. It’s still under construction, but I am refining the logic, and right now I am keeping track of which direction to bank if you use track selectors on the mackie controller, and I’m considering options for figuring out a faster algorithm for auto-banking, which really shouldn’t be too bad. I migrated the script to work in python 3 now. I am re-writing the midi loop now in a way where it should have significantly better performance, and no need for a sleep timer (probably, but initial tests seem to indicate there’s no need anymore now). I got inspired to go back in with coding, now that i was having some issues with the current script using the Mac OS IAC midi devices, as they apparently have some new behaviour since Big Sur or Monterey. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |