Hi All!
I decided to buy a new midi keyboard
controler, and I noticed that allmost
all of the new controlers are suporting
USB for MIDI. My Q is, Is there a way
to control Scope Synth with a USB without
a Sequencer...? I know that I can use the
MIDI port on the controler, but I Prefer
doing it all thro the USB.
Thank you.
USB => Scope MIDI
-
BingoTheClowno
- Posts: 1722
- Joined: Wed Nov 12, 2003 4:00 pm
- Location: Chicago
- Contact:
What is Midex, hope it's not this: http://www.midex.com 
But on a serious note, the problem with MIDI over USB is latency. I just did a Google search for you. Read it here:
http://www.google.com/search?hl=en&lr=& ... ncy+issues
Regarding HT, what exactly is the issue with MIDI?
But on a serious note, the problem with MIDI over USB is latency. I just did a Google search for you. Read it here:
http://www.google.com/search?hl=en&lr=& ... ncy+issues
Regarding HT, what exactly is the issue with MIDI?
Here's Steinberg's Midex 8, they also have a Midex 3.
Using Midex, you could send back into CW cards via hardware MIDI io. This would bring better timing I think, since all your MIDI hardware now is controlled by the LTB protocol.
Emagic has the same with their Unitor/AMT product range. It's a standard MIDI interface when used by other programs, but in combination with their sequencer it provides tighter MIDI timing.
Using Midex, you could send back into CW cards via hardware MIDI io. This would bring better timing I think, since all your MIDI hardware now is controlled by the LTB protocol.
Emagic has the same with their Unitor/AMT product range. It's a standard MIDI interface when used by other programs, but in combination with their sequencer it provides tighter MIDI timing.
more has been done with less
https://soundcloud.com/at0m-studio
https://soundcloud.com/at0m-studio
Use MIDIoverLAN+:
http://www.musiclab.com/products/rpl_info.htm
and create a local pipe. It works like charms.
Cheers,
Cochrane
http://www.musiclab.com/products/rpl_info.htm
and create a local pipe. It works like charms.
Cheers,
Cochrane
-
BingoTheClowno
- Posts: 1722
- Joined: Wed Nov 12, 2003 4:00 pm
- Location: Chicago
- Contact:
Check out the url from my previous post, steiny's site should have the info on LTB.
It's like some sort of latency compensation for MIDI. Using their proprietary protocol, they can add time stamps to MIDI events, send them a little beforehand and the machine will know when to send events that happen simultaneously on different ports, simultaneously.
Using classical MIDI, which is a serial connection, the events would be spit out one after the other instead of simultaneous. One (hardware) MIDI port can typically provide adequate bandwidth for 4 channels of polyphonical playing on a MIDI device.
Do note, once the messages are on a single MIDI port (=cable), they are back in serial, as defined by MIDI protocol and priority rules.
This LTB offers quite an advantage over an other option we have: sending from the sequencer to SFP software ports, next to a single MIDI hardware port, on which no 2 events can occur simultaneously. This can be problematic if you want to control multiple MIDI devices from that one port.
I hope this makes a bit sense
It's like some sort of latency compensation for MIDI. Using their proprietary protocol, they can add time stamps to MIDI events, send them a little beforehand and the machine will know when to send events that happen simultaneously on different ports, simultaneously.
Using classical MIDI, which is a serial connection, the events would be spit out one after the other instead of simultaneous. One (hardware) MIDI port can typically provide adequate bandwidth for 4 channels of polyphonical playing on a MIDI device.
Do note, once the messages are on a single MIDI port (=cable), they are back in serial, as defined by MIDI protocol and priority rules.
This LTB offers quite an advantage over an other option we have: sending from the sequencer to SFP software ports, next to a single MIDI hardware port, on which no 2 events can occur simultaneously. This can be problematic if you want to control multiple MIDI devices from that one port.
I hope this makes a bit sense
more has been done with less
https://soundcloud.com/at0m-studio
https://soundcloud.com/at0m-studio
-
BingoTheClowno
- Posts: 1722
- Joined: Wed Nov 12, 2003 4:00 pm
- Location: Chicago
- Contact:
Well, one thing that bothers me with MIDI over USB is that USB can share its bandwidth if more than one device is connected to the hub. I am a little bit familliar with USB and I could tell you that USB signal is traversing a lot of layers before reaching to the sequencer. There's the USB Hub driver, then the USB Host controller etc (see the whole chain here: http://msdn.microsoft.com/library/defau ... o_4uuf.asp ). It makes me wonder how the hell they can even achieve 1ms latencies with this!
There is a utility called Bushound that can trace the USB activity and anyone can see the overhead and what a bloated protocol USB is. First, USB is not a FULL Duplex communication protocol, all requests are initiated by the host (your computer) and the clients (USB devices, like mice, USB MIDI controllers) just reply, they cannot interrupt the host or initiate a request. For example, on the serial port, when there's data, an interrupt is triggered (data ready pin I think) and the controller reads the buffer. With USB no, all clients can only reply. That's a serious limitation. So, Steinberg probably is using the interrupt transfer method (the fastest way to move data (short data) on USB) that polls the clients every 1ms (maximum possible) and then the USB device (USB controller) is queuing and handling those requests as needed (
rough estimation). When you have two devices (not even thinking of more than two) on the same hub, I don't think the hub can guarantee one device the polling interval of 1ms, the second device wants to send data too. And then you get to the Windows part, the only time Windows was capable of some real time handling was in the days of Win 3.1, 95 and 98 with all the problems that it brought with it, the user programs wreaking havoc after directly accessing the hardware.
Now compare the device chain in the link with the fact that the simple MIDI connection goes directly into and is processed by any of the CW cards before reaching the driver stack.
<font size=-1>[ This Message was edited by: BingoTheClowno on 2004-05-05 13:15 ]</font>
before reaching to the sequencer. There's the USB Hub driver, then the USB Host controller etc (see the whole chain here: http://msdn.microsoft.com/library/defau ... o_4uuf.asp ). It makes me wonder how the hell they can even achieve 1ms latencies with this!There is a utility called Bushound that can trace the USB activity and anyone can see the overhead and what a bloated protocol USB is. First, USB is not a FULL Duplex communication protocol, all requests are initiated by the host (your computer) and the clients (USB devices, like mice, USB MIDI controllers) just reply, they cannot interrupt the host or initiate a request. For example, on the serial port, when there's data, an interrupt is triggered (data ready pin I think) and the controller reads the buffer. With USB no, all clients can only reply. That's a serious limitation. So, Steinberg probably is using the interrupt transfer method (the fastest way to move data (short data) on USB) that polls the clients every 1ms (maximum possible) and then the USB device (USB controller) is queuing and handling those requests as needed (
rough estimation). When you have two devices (not even thinking of more than two) on the same hub, I don't think the hub can guarantee one device the polling interval of 1ms, the second device wants to send data too. And then you get to the Windows part, the only time Windows was capable of some real time handling was in the days of Win 3.1, 95 and 98 with all the problems that it brought with it, the user programs wreaking havoc after directly accessing the hardware.Now compare the device chain in the link with the fact that the simple MIDI connection goes directly into and is processed by any of the CW cards before reaching the driver stack.
<font size=-1>[ This Message was edited by: BingoTheClowno on 2004-05-05 13:15 ]</font>
I would get such a machine if I ever started using my hardware as sound source again, for now I mainly use it to control the DAW. Yes, USB is an 'inferior' protocol, it's disabled on my DAW. But if I needed lots of MIDI hardware IO, I would surely get a Midex or something. Using these patchbays with programs that don't recognise the proprietary MIDI protocol, the suffer from serial connection problems and I won't put my money on the timing, it's likely to suffer USB problems. But here's why I think it's the solution for bad MIDI timing, and probably also for the hyperthreading problem.
The real advantage of using the right host for a proprietary protocol USB MIDI patchbay is that it recognises the time-code sent with the MIDI data. When recording, the sequencer can place the MIDI (which you played on the keyboard) on the track at exact time as it was received by the MIDEX/Unitor. The same happens when you playback a sequence, but in reverse: the MIDI from the tracks is sent too early, and the patchbay keeps it in a buffer until it should be sent out to its hardware ports. As long as the data travels to different hardware ports, it cannot collide.
Using CW midi drivers and squeeze data throught a single hardware cable to a splitter box for a sampler, some synths and external effects, timing will cause problems: for 2 events leaving the sequencer, a dsp device reacts to its event at the same time as the hardware ports outputs its event. Next comes a 4-10ms delay, for a hardware synth or sampler. MIDI's getting old
The proprietary USB (Unitor was also on serial port) protocol uses the same principle as Latency Compensation for VST plugins, there's no time correction for stuff that is monitored/routed through the sequencer, for example from keyboard to VSTi or Scope MIDI driver. But there's some 'direct monitoring': data from one hardware port to another (=thru-put on the patchbay) follows the classical MIDI rules.
The proprietary protocol offers the best timing, and also let's you configure the patchbay from in the sequencer, see the direct monitoring.
PS: I once had a setup with 2 pc's with Cubase, some samplers and synths. I didn't know any better, followed the shop's advise and got home with 2 Emagic patchbays. It was my worst buy ever. I should have gotten Midex' instead. The Unitors are sold, I'm gratefully borrowing a patcher/merger from b0rg since, it works great for my use.
The real advantage of using the right host for a proprietary protocol USB MIDI patchbay is that it recognises the time-code sent with the MIDI data. When recording, the sequencer can place the MIDI (which you played on the keyboard) on the track at exact time as it was received by the MIDEX/Unitor. The same happens when you playback a sequence, but in reverse: the MIDI from the tracks is sent too early, and the patchbay keeps it in a buffer until it should be sent out to its hardware ports. As long as the data travels to different hardware ports, it cannot collide.
Using CW midi drivers and squeeze data throught a single hardware cable to a splitter box for a sampler, some synths and external effects, timing will cause problems: for 2 events leaving the sequencer, a dsp device reacts to its event at the same time as the hardware ports outputs its event. Next comes a 4-10ms delay, for a hardware synth or sampler. MIDI's getting old
The proprietary USB (Unitor was also on serial port) protocol uses the same principle as Latency Compensation for VST plugins, there's no time correction for stuff that is monitored/routed through the sequencer, for example from keyboard to VSTi or Scope MIDI driver. But there's some 'direct monitoring': data from one hardware port to another (=thru-put on the patchbay) follows the classical MIDI rules.
The proprietary protocol offers the best timing, and also let's you configure the patchbay from in the sequencer, see the direct monitoring.
PS: I once had a setup with 2 pc's with Cubase, some samplers and synths. I didn't know any better, followed the shop's advise and got home with 2 Emagic patchbays. It was my worst buy ever. I should have gotten Midex' instead. The Unitors are sold, I'm gratefully borrowing a patcher/merger from b0rg since, it works great for my use.
more has been done with less
https://soundcloud.com/at0m-studio
https://soundcloud.com/at0m-studio
-
BingoTheClowno
- Posts: 1722
- Joined: Wed Nov 12, 2003 4:00 pm
- Location: Chicago
- Contact:
I don't know if the USB protocol that Steinberg is using is propietary, if it were it wouldn't be able to talk to the PC's hub which is USB compliant. I just think (or hope) they are doing something clever in their USB controller that compensates the latencies of USB.
If you have multiple MIDI devices, that's when the MIDI clock or sync signal comes in handy (the signal that wreaks havoc to CW cards).
I know MIDI protocol is old, but it's proven and tested in time.
2 MIDI events? MIDI is Full duplex, so you can receive while sending MIDI. I'm not sure I understand this.Using CW midi drivers and squeeze data throught a single hardware cable to a splitter box for a sampler, some synths and external effects, timing will cause problems: for 2 events leaving the sequencer, a dsp device reacts to its event at the same time as the hardware ports outputs its event.
If you have multiple MIDI devices, that's when the MIDI clock or sync signal comes in handy (the signal that wreaks havoc to CW cards).
I know MIDI protocol is old, but it's proven and tested in time.
re: proprietary USB
Hm... their USB protocol isn't different, but the way Cubase or Nuendo handle the hardware ports is different from the way Cubase would handle a Unitor: it would just see 8 Windows MIDI drivers, not knowing port4 & 7 are on a patchbay and unable to handle routing options within the hardware.
The same clumsy way Logic would deal with a Midex or any program that doesn't recognise the 8 IO as a patchbay, let alone it can control its routing options (direct monitoring).
re: 2 MIDI events
Let's say a sequencer sends 2 'note on' messages at the same time over a MIDI driver. C1 to a DSP device, C2 to a hw synth. Once on dsp, both notes follow a different path, C1 remains there and C2 is routed outboard, with a bit extra latency.
Using a patchbay with LTB, both 'note on' messages will follow a similar path, both have exactly the same latency, which is compensated for by the LTB or whatever the protocol is called. 2 events is a bit of a ridiculus situation, but problems increase quick if you use a bunch of MIDI devices intensively through that one Midi port on the back of Pulsar.
If the hyperthreading problem has to do with Scope MIDI drivers or you think CW MIDI drivers don't work for you, a patchbay can fix that. And I'm convinced the best option is the one made by your sequencer manufacturer.
Hm... their USB protocol isn't different, but the way Cubase or Nuendo handle the hardware ports is different from the way Cubase would handle a Unitor: it would just see 8 Windows MIDI drivers, not knowing port4 & 7 are on a patchbay and unable to handle routing options within the hardware.
The same clumsy way Logic would deal with a Midex or any program that doesn't recognise the 8 IO as a patchbay, let alone it can control its routing options (direct monitoring).
re: 2 MIDI events
Let's say a sequencer sends 2 'note on' messages at the same time over a MIDI driver. C1 to a DSP device, C2 to a hw synth. Once on dsp, both notes follow a different path, C1 remains there and C2 is routed outboard, with a bit extra latency.
Using a patchbay with LTB, both 'note on' messages will follow a similar path, both have exactly the same latency, which is compensated for by the LTB or whatever the protocol is called. 2 events is a bit of a ridiculus situation, but problems increase quick if you use a bunch of MIDI devices intensively through that one Midi port on the back of Pulsar.
If the hyperthreading problem has to do with Scope MIDI drivers or you think CW MIDI drivers don't work for you, a patchbay can fix that. And I'm convinced the best option is the one made by your sequencer manufacturer.
-
BingoTheClowno
- Posts: 1722
- Joined: Wed Nov 12, 2003 4:00 pm
- Location: Chicago
- Contact:
Keep in mind, in order to use the USB-V2.0 with high-speed capability, the USB-V2.0 host from PC is required. Most of new PC/Mother-board are shipped with 8 ports of USB-V2.0 now, otherwise, with old PC, you might need the add-on PCI card.
Technically, For the MIDI with the used of USB-V2.0 does not need the 480MBS bandwidth but it has the 8 times better latency. For instance, instead of 1 mili second on the USB 1.x, the USB 2.x has the latency about 1/8 of mili second, it's called micro-frame, which is about 125us.
You should be able to find the USB 2.0 MIDI adapter somewhere? Have you tried the MIDIMAN, ROLAND/EDIROL or YAMAHA?
If we could not find it, maybe it doesn't need to be USB 2.0 due to be in-expensive matter?
Refer to the link as follows:
http://www.edirol.com/products/info/um1sx.html
With the FPT (Fast Processing Technology of MIDI transmission) enhancement should solves well in MIDI latency problem on the USB-V1.x.
Again, when we find the USB2.0 MIDI, it should works well without the FPT.
Hope this helps,
LongStudio
<font size=-1>[ This Message was edited by: LHong on 2004-05-06 18:36 ]</font>
Technically, For the MIDI with the used of USB-V2.0 does not need the 480MBS bandwidth but it has the 8 times better latency. For instance, instead of 1 mili second on the USB 1.x, the USB 2.x has the latency about 1/8 of mili second, it's called micro-frame, which is about 125us.
You should be able to find the USB 2.0 MIDI adapter somewhere? Have you tried the MIDIMAN, ROLAND/EDIROL or YAMAHA?
If we could not find it, maybe it doesn't need to be USB 2.0 due to be in-expensive matter?
Refer to the link as follows:
http://www.edirol.com/products/info/um1sx.html
With the FPT (Fast Processing Technology of MIDI transmission) enhancement should solves well in MIDI latency problem on the USB-V1.x.
Again, when we find the USB2.0 MIDI, it should works well without the FPT.
Hope this helps,
LongStudio
<font size=-1>[ This Message was edited by: LHong on 2004-05-06 18:36 ]</font>
-
BingoTheClowno
- Posts: 1722
- Joined: Wed Nov 12, 2003 4:00 pm
- Location: Chicago
- Contact:
Thanks. My new Pc does have USB 2 capability installed. Are you saying a USB2 port will provide some latency improvements for any USB device - including those made for USB 1, or do they have to be specifically made for the new protocol? (like the new Edirol audi interface)On 2004-05-06 13:16, LHong wrote:
Keep in mind, in order to use the USB-V2.0 with high-speed capability, the USB-V2.0 host from PC is required. Most of new PC/Mother-board are shipped with 8 ports of USB-V2.0 now, otherwise, with old PC, you might need the add-on PCI card.
Technically, For the MIDI with the used of USB-V2.0 does not need the 480MBS bandwidth but it has the 8 times better latency. For instance, instead of 1 mili second on the USB 1.x, the USB 2.x has the latency about 1/8 of second, it's called micro-frame, which is about 125us.