dbsys wrote:Are you aware of the Steinberg SMP II? It was the successor of the SMP 24, but follwed a different route. While the SMP 24 was a complete stand alone MIDI processing system, the SMP II only featured MIDI I/O and SMPTE I/O. It is probably a lot simpler to reverse-engineer.
Thanks, I'll have a closer look at how the drivers differ. Taking a guess, I would say the MIDI part of the SMP24 works the same way as the SMPII since that would save them having to re-engineer anything. Maybe the internal firmware is the same, just devoid of the user interface and therefore unable to utilise the dormant patchbay features?
I'd be interested to know whether the SMPII could be made to work in Pro24 - that would confirm whether the protocol is the same. Speaking of Pro24, I should get around to doing some MIDI performance tests to see how it compares to Cubase. Being simpler, I wouldn't be surprised if it were faster!
Any idea how much SMPIIs go for these days? They don't seem to be very common. It would be much easier to reverse-engineer one by hooking a logic analyzer up to it!
Interesting - I didn't know it was made by Waldorf. I don't think the Midex is made by them? I would hope it's pretty high-quality engineering with a name like that behind it. That said, the Midex looks pretty well-engineered too, a nicer design than the Unitor (although the MIDI performance of both should be identical). I was a bit puzzled why the Midex uses 150 ohm resistors on its optoisolators - that's not really MIDI spec compliant. But surely they had a reason, even if I can't fathom why!
charles wrote:how does your input routine decipher data from the different ports?
is it kept in separate arrays for each port...considering data on channels 0-15 need to be sent using the midi format ?
At the moment I've only implemented MIDI output for the Friend Chip MM1 and SoundPool MO4. The protocol for both is pretty simple, here's how the MM1 works:
10 Wait for busy line to go low
20 Write data byte, pulse strobe low and high
30 Write port number (0-7), pulse strobe low and high
40 Goto 20 until data for all 8 ports has been written
50 Goto 10 until all MIDI events have been written
The busy line will go high upon writing the first byte, but you can still write additional bytes for the other ports - but only one byte per port. The busy line stays high for typically 0.32ms, so you would normally use interrupts to catch it going low again since 0.32ms is too long to waste time polling for.
The SoundPool MO4 is similar, but slightly different:
10 Wait for busy line to go low
20 Write port selection byte, where you set bits 0-3 to select ports 1 (bit 0), 2, 3 or 4. Pulse strobe low and high.
30 Write data byte for first selected port (lowest number), pulse strobe low and high.
40 Goto 30 until all data bytes for the selected ports have been written. Not necessary if only one port was selected.
50 Goto 10 until all MIDI events have been written
I'm not totally sure how the busy line behaves on the MO4 yet. There is some limited buffering available - you can write two bytes for each port without checking the busy line.
Performance-wise, the SoundPool MO4 is a better design since it offers buffering. To fully utilise all ports of the MM1, you need a pretty fast response to interrupts. Or you could be really sneaky and set an MFP timer to interrupt you 0.32ms after writing data, minus the projected interrupt handling latency. Then you could poll until busy goes low in case the interrupt was handled faster than average.
I'm pretty amazed they managed to cram buffering into the SoundPool MO4 actually. It uses a tiny CPLD with probably only something like 64-128 registers. On the other paw, the Friend Chip MM1 seems to have enough logic to implement a one-byte buffer yet doesn't seem to do that.
As far as compatibility goes, I think the MM1 and MO4 should work fine on any system - including a CT60. There's no dependence on CPU speed to govern the timings, and the hardware is very fast. The Steinberg MIDI3 and the SMP24/II are a different matter - they use a CPU internally, so it's important to follow the timings exactly. It would be interesting to know if those devices work on a CT60 - if so, they must have used handshaking or an MFP timer to control the timings.
charles wrote:would it make more sence to store a sequencer's midi data on external device storage (a new modernized smp midex etc )
,,then from within the program with one single command trigger the output ...so like somesort of external trigger to the device connected to serial port..midi port ,printer port......
It's an interesting idea, and definitely a possibility if you want the tightest timing possible. Of course, you'd probably have to write to-the-metal code on the Raspberry Pi to make that possible - Linux is likely too inefficient to handle MIDI fast enough. But then, you could just slap a user interface on there and make a standalone Raspberry Pi MIDI sequencing box with no Atari needed.
It would be quite a lot of work since you'd need to implement USB and everything if you're going to throw Linux out. You could implement a MIDI interface device that way, with a printer port interface and some MIDI outs. Unfortunately, I'm not sure how to write to-the-metal code on the Raspberry Pi.
There are a handful of USB IBM compatible MIDI interface devices which take a slightly different approach. They use the sequencer to send the data to the device ahead of time, the device then takes care of controlling timing. This can give you extremely tight MIDI output timing. Unfortunately, it's plagued with problems in practice. There are all sorts of software compatibility problems which means that often time stamps don't get sent from your sequencer through to the device, negating the advantage. Some of those devices don't provide any time stamping for MIDI input, so your MIDI input has jitter all over the place. And AFAIK, none of the devices offer MIDI thru - so you have massive latency and jitter whenever you play the keyboard live. In theory all those problems could be solved by close cooperation between the sequencer developers and the hardware company, but that's about as likely as pigs flying. Sequencer developers these days seem to be focused squarely on software synthesisers and USB keyboards, and I wouldn't be remotely surprised if they remove external MIDI device support from them in the future. Logic's external MIDI device support these days seems to be relegated to a dark corner.
If that happens, the only way to get MIDI output will be to use a device like that thing made by Expert Sleepers which converts audio into MIDI. That can also give you very tight MIDI output timing, but only a single port. And forget about MIDI input and MIDI thru. Funnily enough it's an idea I thought of many years ago when USB was beginning to take over - but I decided the latency problems would make it pointless.
In terms of making a new interface device, that's pretty much what I'm planning. The device will attach to the printer port and will give you at least 2 MIDI inputs and 8 MIDI outputs - and it will be cheap to make using modern components. I could support that in my own MIDI sequencer, but people will also want to use it in Cubase. For that reason, I'm taking a two-pronged approach to Cubase compatibility. First, I'm going to implement support for the Friend Chip MM1 (and possibly Midi3 / SMPII) protocols in the hardware - selected with a DIP switch. When in this mode, it will work in Cubase with the existing driver. Secondly, I hope to learn enough about how Cubase drivers work to write a from-scratch Cubase driver which can take advantage of simultaneous MIDI input and output (the Friend Chip protocol only allows MIDI output). I can't promise anything in that regard since Cubase drivers are fairly complex and I have no documentation - but I'm slowly making some progress with disassembly.
Notator support is much trickier since it doesn't have a driver architecture. I'm not really sure how I could add support for a printer port device to Notator at all. It's remotely possible I could add support for a fast modem port interface to Notator, but then does anyone need that? If you install the Log3, it will take over from the modem port anyway. I could possibly make a clone of Unitor, and I'll look into that after I've done the printer port device. But I can't see a way of adding additional outs to Notator above what it already supports. It's a shame C-Lab/Emagic never added support for printer port devices, but I guess they wanted to sell their own expensive cartridge port devices.
edingacic wrote:does smpII work on TT030?
Did you need to modify your Midex to get it working with the TT? I know there's a mod for the Falcon which I assumed was for 68030 compatibility. But if it works with the TT without modification, I really have no idea why the Falcon mod is necessary. I heard there was some compatibility difference between the ST and Falcon cartridge ports, but I've looked at the schematic and can't find out why.
The good thing about the printer port is that it's identical between all Atari models. So barring some kind of compatibility problem in the driver (which could probably be patched), any printer port device should work on any Atari. The Firebee, I'm not so sure about. I tried e-mailing them to find out some technical specs on the Firebee's printer port, but haven't heard back. There could be some electrical differences between the Firebee and Atari which makes it incompatible with the SMP24/II and Midi3 - or even unsafe to attempt to connect it. But as far as I can tell, the SoundPool MO4 and Friend Chip MM1 will work on any printer port - even on an Amiga or IBM. The problem comes when you try to read data back from the device like the SMP24/II and Midi3 need - there could be a bus conflict unless the printer port is open-collector. IBMs don't have open-collector ports, and it's possible the Firebee might not either.
The Midi3 does have a set of jumpers to reconfigure it for the IBM, and in this case it would be safe to connect it. But of course it won't work with the Atari or Firebee if you jumper it that way, since the Atari lacks the additional four input pins the IBM has. That's also why you can't use IBM printer port rack mount interface devices on an Atari - they're simply incompatible at the hardware level. But funnily enough, you could use one of those 8-out/8-in Macintosh interfaces on an Atari with a LAN port. It just needs someone to write a suitable driver (but don't expect full 8-port maximum bandwidth performance, since no Macintosh interface can deliver that). Simple 1-out/1-in Macintosh interfaces already work with Cubase using LANPORT.DRV - and you can build your own with a few components.
I'm planning to write a simple MIDI patch bay program for the Atari, once I've learned how the various MIDI interface devices work. This will turn the Atari into a multi-input multi-output MIDI patchbay and merger. I'm not sure if anyone needs such a program, but I need to write it anyway - since the exact same code is an important part of a MIDI sequencer.
Progress so far:
Friend Chip MM1: I know enough to program it, and nearly enough to clone it 100%.
SoundPool MO4: I also know enough to program it, but I need to finish analyzing the data to clone it.
Midex: I know how it performs writes, but I need to figure out where the registers are mapped. Then it's possible to program it, and even clone it.
Unitor: Similar to the Midex, although I don't know how it performs writes yet.
Midi3: The only thing I know so far is that it's a nibble-wide protocol.
SMP24/II: No idea yet
Log3: Also unknown, but should be simpler than the SMP24/II and Midi3.
My focus at the moment is on the printer and modem ports - I'll only look into cloning the cartridge devices later. It's trickier because the speeds are higher, but also mechanically. I'd need to find someone who can make a suitable case which can fit in the cartridge port, which has quite particular mechanical requirements. My CAD skills are zero. It might also be tricky to find the 2mm connector the cartridge port uses.
I'm also keeping an eye on that project to clone the Cubase dongle. If they succeed, it would be interesting to have a single device which integrates the dongle and Midex. Probably don't even need the tricky-to-find cartridge port socket then, because there's no need to plug a dongle in. Of course Notator users will still need a dongle socket since I'm not aware of any project to clone the Notator dongle.
edingacic wrote:I have sent the file for MM1 testing and as soon as I get this data back I will post it here.
Would your friend be willing to run another test program on the MM1? There's just one more question I have about how the protocol works. This test will be much faster than the previous one, just a few seconds.
If not then I understand, and I think I already have enough information to make a more-or-less clone of the MM1.
His help as well as yours is very much appreciated so far!