Hi Jens,
I’ve created a new version which should work better now, but not all “imperfections” can be fixed, due to various reasons.
-> http://www.ucapps.de/mios/midibox_sid_v1_7_303beta9.zip
I wrote about the reasons some time ago, but since the answers are spreaded over this forum, I will summarize them here (with some new insights and outlooks)
additional hardware for TB303 sequencer: thats possible, my private blocking point is, that I haven’t found a nice case for a “breakout box” yet (which then will be connected to a joystick port of the C64 case). I don’t want to start with the implementation before I’ve a ready-built hardware, because it makes a big difference when everything is right in place before the programming phase, or if some stuff can only be prepared but not be tested.
Play mode: yes, thats a known “problem”. I had to decide if I either send a “play command” via SysEx, or via a common MIDI note. I prefered to use a MIDI note, since it is transfered faster (minimum latency) and since it is compatible with the old PIC16F hardware (I didn’t know that your slave uses it - but it seems that it was good that I considered this)
Sending a note instead of SysEx has also the advantage, that if SIDs are assigned to the same channel, they will be started at exactly the same time without a delay. Doing the same with SysEx would mean that I would have to implement something like a “broadcast” function (SysEx message which is taken independent from the Device ID), and this would increase the code size too much for such a minor feature. For the PIC16F firmware it wouldn’t be possible (out of memory)
Continue playing while changing a complete patch: this would lead to many unwanted side effects and wouldn’t work properly in all cases. A patch change does not only refresh the SID registers, but especially resets the whole sound engine, which is so mighty like a soft synth. There are many dependencies between the registers (values which have to be stored and written back after the change), which makes such a feature to a mess for a programmer.
A proper patch change without reset would also require that the whole patch data is transfered to the SID as well as to the sound engine within one update cycle (0.8 mS), this is not possible with the PIC. It’s especially not possible to send so much data to the slaves within this short timewindow, since the transfer takes ca. 260 mS.
Update of incoming CC values: it should work better now, parameters to the master SID are updated regardless of the menu page. The change will be visible after one second (worst case), but it should never got lost now (in edit mode!)
Update of CCs to slaves: nearly impossible with the concept. At the time where I started with the implementation of the SID application on the PIC18F I had to decide how to store the data structures. I choosed a dual storage method: one compressed structure which reflects the SysEx dump and which is easy (and fast) to handle for the control surface when multiple SIDs have to be serviced, and another structure which is optimized for the sound engine. A third structure is given by the CC->parameter assignments, but this is (fortunately) not stored in memory, but directly transfered into the SID and SysEx memory.
This works fine in most cases, but it has disadvantages which must be accepted. E.g., since it is possible to change multiple parameters with a single CC (e.g. CC#16 which changes the transpose value of all three oscillators), an incoming CC cannot be easily mapped to a byte in the SysEx structure.
The current solution is to read back the data from the sound engine data storage and copy it into the SysEx storage when the CPU has some free time. This works fine, but only for the master SID, because the control surface has no access to the sound engine storage of the slave SIDs (unidirectional interface…)
Another solution could be to write a large function which decodes the incoming CCs and passes them to the appr. registers of the SysEx structure. This would work for the master and the slaves, but it would consume so much code memory, that other features would have to be removed. Therefore I prefered the “cheaper” solution.
There are two good points which I want to mention here:
-
for the MIDIbox FM I solved such problems very early in the design phase - MBFM has a single data structure which is optimized for SysEx/CC and OPL3 accesses (it took some time to find out all relationships) - so, in MBFM the data is always consistent
-
sometimes I’m thinking about a major redesign of the SID application which doesn’t consider compatibility issues, but results into an “perfect” implementation based on my experiences in the last years. But on the other hand I think that the current implementation isn’t that bad, that everybody can live with such imperfections when he knows how to handle with it…
However, just another remark: if the PIC18F4620 wouldn’t have that f*cked EUSART and CPU bugs, all these issues wouldn’t exist anymore, because this chip offers twice the flash memory, and much more RAM… the existing firmware could be freely extended without such “50% solutions”. So, my hope is, that Microchip releases a new chip revision, so that it is possible to make the application perfect without the previously mentioned redesign.
Best Regards, Thorsten.
