Forum Replies Created
-
Posts
-
I see the Indiegogo is closed, even though the link is still there at ctrlr.org
I wonder if there’s any possibility @Atom will reopen it?
I’m currently working on a project that has strong interest within a community and will be directing anybody who wants to contribute towards my efforts to instead donate towards Ctrlr.
This would run the latest OS X and Xcode, would this do the trick?
http://www.ebay.com/itm/Apple-Mac-mini-2010-model-2-GB-RAM-320GB-drive-OS-Sierra-VG-/272564539792?hash=item3f761cd190:g:K48AAOSwtfhYomXv
@atom if we can raise the funds for a decent Apple dev machine, what would you say is the likelihood of an iPad/iPhone release? I think Ctrlr could get much stronger traction and wider use on there.I’m just getting going with Ctrlr on Mac right now… is this still an issue or did you raise sufficient funds for a Mac? Sorry to see that you’re providing so much development but have difficulty getting the hardware to help
Well, this was my first time writing Lua (I’m not a programmer by any stretch of the imagination). This is what I came up with for the Axe-FX II checksum, and… it works!!
y = bit.bxor(0xF0, 0x00, 0x01, 0x74, 0x06, 0x02, 0x6A, 0x00, 0x27, 0x00, numericModulatorValue, 0x00, 0x00, 0x01)
n = bit.band(y,0x7F)
m = CtrlrMidiMessage({0xF0, 0x00, 0x01, 0x74, 0x06, 0x02, 0x6A, 0x00, 0x27, 0x00, numericModulatorValue, 0x00, 0x00, 0x01, n, 0xF7})So… I guess in order to implement my own checksum calculations and attach that to a modulator, I should be using “Called to calculate the MIDI value to send”?
Can anyone point out a sample panel that does that? So far for reference I’ve been poking through the Prophet 6 panel and not seeing anything like that.
Ok, there was a error with the method used, but I still don’t get the exact checksum.
Let’s go with you first message: F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 4D F7
Once you XOR all the bytes (F0^00^01^74^06^02^6A^00^27^00^00^00^00^01) the result is CD
Now the error: you must add CD to 7F (CD + 7F = 14C) and remove the leftmost bit: 14C –> 4C
The checksum we get is 4C, but it should be 4D
With the last message you provided, I get the same result:
F0 00 01 74 06 2A 29 F7
F0^00^01^74^06^2A = A9 — A9 + 7F = 128 —> checksum = 28 and it should be 29.We are really close.
Hrm, I tried using the calculator here:
http://www.miniwebtool.com/bitwise-calculator/?data_type=16&number1=a9&number2=7f&operator=ANDYour XOR to get a result of A9 seems correct. Its the last step where something isn’t right in your calculation.
I used the tool to AND A9 to 7F and got the expected 29
Thanks a ton for your effort in helping crack this! Unfortunately it seems like quite a bit about the Axe-FX is somewhat unusual or nonstandard. A shame since its a fantastic piece of equipment that is used by many of the most famous guitarists in the world.
Anyway, I’m thinking maybe the below will be useful reference since it shows how the checksum ends up with only one byte changed?
Turn Amp 1 bright switch on
F0 00 01 74 06 02 6A 00 27 00 01 00 00 01 4C F7
Turn Amp 1 bright switch off
F0 00 01 74 06 02 6A 00 27 00 00 00 00 01 4D F7Hrm, maybe try this? I don’t know what this message means, but its much shorter:
F0 00 01 74 06 2A 29 F7I think that’s a response message back *from* the Axe-FX II, but per the documentation the response messages also use a checksum which I would assume are calculated the same way.
Thanks dasfaker! I’ll try your formulas but yes doesn’t seem like it will match.
In the example I provided with the 4D checksum, I had grabbed that example command by monitoring the output of the Axe Edit desktop application, which I believe calculates the checksum for each command and appends it before sending.
