Type definitions
~~~~~~~~~~~~~~~~
00: Voice #1, EEPROM access (exception: command #06 always accesses RAM)
01: Voice #2, EEPROM access (exception: command #06 always accesses RAM)
02: Voice #3, EEPROM access (exception: command #06 always accesses RAM)
03: Voice #4, EEPROM access (exception: command #06 always accesses RAM)
08: Voice #1, direct RAM access
09: Voice #2, direct RAM access
0A: Voice #3, direct RAM access
0B: Voice #4, direct RAM access
10: Drums, EEPROM access
18: Drums, direct RAM access
70: Ensemble, EEPROM access
78: Ensemble, direct RAM access
[/code]
> I'm using Ctrlr 965 on Mac OS X (10.6.8)
This is the actual issue - please use r946, you will find the link in the first posting!
Best Regards, Thorsten.
Open the Lua source code viewer, select the “receiveMIDI” tab.
It shows you a program that I wrote to map incoming SysEx data to the controllers.
This part is relevant for the Attack controllers:
assignModulator(mem_block:getByte(0x20), "OP1Attack")
assignModulator(mem_block:getByte(0x21), "OP2Attack")
[/code]
as you can see (when you read & (!) understand the code a little bit more), the controller name is relevant.
So: your experiment will work if you change the controller names in these function calls as well.
Best Regards, Thorsten.
Beim weiteren Durchschauen sprang mir grad noch ins Auge, dass die Parameter Keyscaling für OP1-4 an den Drehreglern alle auf 0x24 gestellt waren, statt 0x18-0x1b.
Ich bin noch nicht durch, wenn ich noch was finde werd ichs hier posten.
Die verbesserte Version lad ich hoch, wenn alles durchgecheckt ist.
[EDIT]
SHORT ENGLISH VERSION:
I found some bugs in the panel but need more time for investigation before i will upload a fixed version.
Wäre das so nicht richtig, wenn ich CC32 auslassen will und die folgenden CCs bis zum nächsten freien CC um 1 zu “shiften”?
Also von 0x20-0x34 nach 0x21-0x35
The MBFM firmware doesn’t allow to shift CCs by 1, because sometimes logical operations such as “>>2” or “&3” are used to determine the parameter type and operator number!
The only way I see would be to move all 4 OP Attack parameters to an unused range which is dividable by 4, such as 0x34..0x37
Ich hab übrigens nen Fehler im jetzigen Panel gefunden, OP4 Sustain hat nen falschen Wert. (2f statt 2c)
0x2b is the correct value.
Beim weiteren Durchschauen sprang mir grad noch ins Auge, dass die Parameter Keyscaling für OP1-4 an den Drehreglern alle auf 0x24 gestellt waren, statt 0x18-0x1b.
I fixed this and upoaded a new version to the Device Database
Die verbesserte Version lad ich hoch, wenn alles durchgecheckt ist.
Not required, it would be more helpful if you would describe the errors so that I can doublecheck if your assumption is correct and do the actual change on the “master panel” which will be uploaded to the device database.
Especially since you are doing changes which will only work with your modified firmware (CC moved to different location), your uploaded panel would only confuse people and lead to unnecessary “bug reports”
I finally fixed the display on my MBFM and gave this another spin. I am curious as to if there is a way to send a patch change even using the interface? I wasn’t able to find it, although the converse works (pulling in the current patch from MBFM). That functionality would be nice if I was able to record the bank change from CTRLR into a MIDI/automation track in Ableton Live (thereby having a nice work around for Live’s own poor handling of bank/patch changes).
I’ll check that out! Seems pretty straightforward to add things. Only other issue is that changes on the panel weren’t being sent back to Live as MIDI events so I’ll still need to figure that one out.
