My latest interface project involves a boatload of sysex. It might make life a little easier if I could put this data in an external library. Will Control access it and if so, where in the iOS folder structure should I put the file so it can be loaded by Control? (BTW I have full access to the file system through iFile.)
Thanks,
Scott
How are you sending / processing the sysex? Is the data a text file?
You can put a file inside of www > js. You can then add the following line to index.htm:
<script src="yourFileName.js"></script> in the head of the html file. If it's a C file or something else the problem is more complicated. - Charlie
Thanks Charlie. No it's not C, just a JSON text file containing parameter names and associated sysex that I want to use in my interface.
Regards,
Scott
Hi All
From my viewing of the code in Control:Plugins:Midi it looks like there could be an issue because only MIDISend is implemented, which will send your standard type midi msgs such as note on/off, CC's, PBend and PgmChng - but not Sysex.
Sysex is sent via MIDISendSysex (not MIDISend) which has different arguments so I think some extra code will be required to achieve what you want. I am not sure how much this would involve as I am a bit of a novice coder, but it should not be too much. Further info available in CoreMIDI:MIDIServices.
I would certainly be interested in getting this feature happening.
Cheers
MM
Yeah, this was why I asked about how he was planning to send the sysex. I don't mind implementing the calls, but you'll probably have to build from source until an app store update; don't know if you have a developers license to do this.
Working on adding this now... it's a little trickier than I thought it would be but I think I'm close.
OK, I've added this in and pushed the changes to the development branch on GitHub. You call it like so:
midiManager.send('sysex', [0xF0, 0x41, 0x10, 0x42, 0x12, 0x40, 0x00, 0x7F, 0x00, 0x41, 0xF7], 11);... where 11 is the number of bytes in the sysex array.
I'm really trying hard to finish up an update for Control and hope to post this change (as well as a bunch of other changes) to the app store soon. - Charlie
Cool
That was quite quick . . Would have taken me a hell of a lot more time, I'm sure . . .
I'll have a look at how you did it a bit later this evening . . .
Unfortunately I don't have Dev Account - yet . . . So can only run in the simulator . . .
Would we be able to look at USB midi via the CCK as well before an AppStore update?
I had a bit of a look and the issue seems to be that only MIDINetwork stuff is implemented, but I think it needs stuff from MIDIServices to access USB midi devices. The selectHardwareMIDI method appears unimplemented . . .
It would be good if this was under a seperate title on the destinations page and also able to deal with multiple devices incase a hub is used. It should also be able to send to both IP and USB ports at the same time I guess.
Not sure where you may be up to in all this - will check the devbranch later
Thanks
MM
These is a tiny bit of code in the dev branch that is commented out... the rescanForSources method adds MIDI devices connected through the CCK. If you uncomment the [self rescanForSources] in the MIDIManager start method those sources should be listed in the Destination Manager.
Unfortunately it doesn't work in the Simulator, but it works on my iPad fine. One problem with implementing this is it's a pain to debug... you have to load the software on the iPad, disconnect the iPad from your computer, plugin the CCK / MIDI interface, test, unplug the CCK, plugin the iPad back in to your computer, load a new iteration etc.
But I'd like to see it happen at some point for sure. Just haven't been able to devote time to it... it will take more time than adding MIDI Sysex unfortunately... - Charlie
OK, so I looked into it some more and it wasn't that hard after all. There's a little bit of cleanup needed but there is now CCK input / output supported in the development branch.
I wish I had known it was only going to take a couple of hours a few months back when I put it on the backburner... oh well. Glad it's in there now! - Charlie
Excellent
I did not think it would take too much to get happening - hope some of my comments helped . . .
Unfortunately I understand the theory and logic behind coding it, but fall short on the practical/implementation side of it all - quite frustrating. Again it would have taken me far, far longer but hopefully look at your code will light my way a bit . . .
Any possibility of sending me a new compiled version? Not sure when I will be able to get the Dev membership to do it myself . . .
Glad that you have got it sorted - will see if there are any other ideas that I can contribute . . .
Cheers
MM
It's a little too buggy at this point to try and get that going. I feel like I would just be fixing bugs and sending out new versions, which is a path I don't want to go down. I do really want to get this update out, so hopefully it won't take too long to finish it and get it approved. - Charlie
No worries,
I guess I should just get the Dev membership . . .
Oh and another thought was whether we can get control to receive and save sysex messages sent to it, dumped from a device?
This would help automate the process of generating correct sysex packets . . . Just a thought . . .
Cheers
MM
Hmmm... I only have support for sending sysex messages right now... but anything can be saved in Control using standard HTML 5 web database or local storage methods. Here's a good summary: http://diveintohtml5.org/storage.html (I highly recommend using local storage vs. the database methods).
To be honest I'm not excited about spending time on receiving sysex but if you or someone has questions about implementing it I'm happy to help. Really just trying to get this update out the door now... - Charlie
Actually, you could send whatever sysex you want as an OSC string and then save it... there's probably no need to implement actual sysex parsing since there's no functionality tied to it in Control.
Yep
No worries - don't want to complicate things . . .
I should just let you get on with the update and follow the code abit better . . .
Cheers
MM
Great thread! I guess it turned out for the best that I didn't mention I was planning on sending the sysex via OSC... ;->
I'm really looking forward to trying the CCK functionality. Thanks Charlie (and Macciza).
Regards,
Scott