Hey!
Wondering if someone has experience of Pulsar I, Midex3 or 8 and Cubase and wants to share? I'm mostly wondering how Pulsar handles the interface when it comes to its SW synths?
/freddan
Midex3/8
Hi there,
I use the Midex-8 in combination with a PulsarI board, and have to say I am very pleased with the timing (See also this <a href="viewtopic.php?topic=2596&forum=1"> post </a>).
The only thing that Pulsar sometimes has problems with is when there is a high quantity of midi-data coming in, for example when sending MTC to the input too, then it will sometimes (1 in 1000 times or so) skip a message (for example with quick volume or filter-gates)
Any other, or more specific issues, I'll be glad to answer.
Regards,
KrasS
<font size=-1>[ This Message was edited by: on 2001-11-05 07:25 ]</font>
I use the Midex-8 in combination with a PulsarI board, and have to say I am very pleased with the timing (See also this <a href="viewtopic.php?topic=2596&forum=1"> post </a>).
The only thing that Pulsar sometimes has problems with is when there is a high quantity of midi-data coming in, for example when sending MTC to the input too, then it will sometimes (1 in 1000 times or so) skip a message (for example with quick volume or filter-gates)
Any other, or more specific issues, I'll be glad to answer.
Regards,
KrasS
<font size=-1>[ This Message was edited by: on 2001-11-05 07:25 ]</font>
Hi,
In fact, I don't use the Pulsar's internal midi-ports in Cubase anymore, but hook the Pulsar up via a cable from the Midex.
After that, you only use the "Pulsar Midi Source" and "Pulsar Midi Destination" modules to hook up your devices.
This is the only way to get the same consistent timing as the rest of your instruments on the Midex.
Anyway, the internal timing Cubase > Pulsar by the Pulsar's midiports is a lot worse, I don't even have them selected anymore in my MME setup.
The only thing is that I THINK that the external midiports can't handle as much info as opposed to using the internal midi-ports (see my comment on the dropouts), but I am not sure about that, and haven't tried to measure it. Can anyone else comment on that?
I'm off for the weekend,
Regards,
KrasS
In fact, I don't use the Pulsar's internal midi-ports in Cubase anymore, but hook the Pulsar up via a cable from the Midex.
After that, you only use the "Pulsar Midi Source" and "Pulsar Midi Destination" modules to hook up your devices.
This is the only way to get the same consistent timing as the rest of your instruments on the Midex.
Anyway, the internal timing Cubase > Pulsar by the Pulsar's midiports is a lot worse, I don't even have them selected anymore in my MME setup.
The only thing is that I THINK that the external midiports can't handle as much info as opposed to using the internal midi-ports (see my comment on the dropouts), but I am not sure about that, and haven't tried to measure it. Can anyone else comment on that?
I'm off for the weekend,
Regards,
KrasS
You get better timing when running midi OUT through an interface and back IN to the pulsar?
This is tighter/faster than the internal port?
Wow, if that's true, I'd think there's some real issues is the software or driver... That internal port should be something like Rewire or a VSTi, basically dead on time. If that's not the case I'd hope Creamware would look into that.
Surely internal midi ports are more flexible and theoretically much tighter/faster.
Someone needs to do the following test:
1. Setup a snare sound (same sound) on two EDS8i's
2. Have one synth internal port, have the other external midi
3. Pan the internal synth hard left, the external synth hard right.
4. Make a simple 4/4 consistant pattern and record to a stereo track.
5. Take a look at the stereo track in Wavelab or Soundforge and see what the offset is and which device is more in time!
If the Midex device is more "on" - Creamware's got some work to do.. that's not acceptable.
- sinix
This is tighter/faster than the internal port?
Wow, if that's true, I'd think there's some real issues is the software or driver... That internal port should be something like Rewire or a VSTi, basically dead on time. If that's not the case I'd hope Creamware would look into that.
Surely internal midi ports are more flexible and theoretically much tighter/faster.
Someone needs to do the following test:
1. Setup a snare sound (same sound) on two EDS8i's
2. Have one synth internal port, have the other external midi
3. Pan the internal synth hard left, the external synth hard right.
4. Make a simple 4/4 consistant pattern and record to a stereo track.
5. Take a look at the stereo track in Wavelab or Soundforge and see what the offset is and which device is more in time!
If the Midex device is more "on" - Creamware's got some work to do.. that's not acceptable.
- sinix
Anyway try checking the timing of any of your MIDI gear... You'll find even hardware synths have a small amount of "midi latency" and really, these midi interfaces with timing protocols really DO help this.
But implementing some proprietary MIDI protocol like ReWire might be interesting, still. Anyway, go make music
<font size=-1>[ This Message was edited by: subhuman on 2001-11-05 09:03 ]</font>
<font size=-1>[ This Message was edited by: subhuman on 2001-11-05 09:03 ]</font>
But implementing some proprietary MIDI protocol like ReWire might be interesting, still. Anyway, go make music
<font size=-1>[ This Message was edited by: subhuman on 2001-11-05 09:03 ]</font>
<font size=-1>[ This Message was edited by: subhuman on 2001-11-05 09:03 ]</font>
I did the test that sinix proposed. Two times, and the result is still some of a mystery to me...
Best result was only 2 samples offset, the software solution first.
The worst result (only once, at the loop marker) was 33ms latency for the software connection.
Generally the software solution seems to be faster by around .2-.4 ms and
MidEx8 seems to be a bit slower, but more stable.
I should redo this test once more, just to be sure.
Best result was only 2 samples offset, the software solution first.
The worst result (only once, at the loop marker) was 33ms latency for the software connection.
Generally the software solution seems to be faster by around .2-.4 ms and
MidEx8 seems to be a bit slower, but more stable.
I should redo this test once more, just to be sure.
I suppose that indeed the soft solution will show less latency, but as long as latency is a stable figure, you can cancel that out by offsetting your tracks...
At the other hand, 33 Ms is a lot of latency, I haven't tested it yet, but with my Midex-8, it is surely less (if not I would have noticed).
Anyway, I'll run the same test tonight, and will record externaly, should give me an objective figure.
I'll keep you up to date!
KrasS
At the other hand, 33 Ms is a lot of latency, I haven't tested it yet, but with my Midex-8, it is surely less (if not I would have noticed).
Anyway, I'll run the same test tonight, and will record externaly, should give me an objective figure.
I'll keep you up to date!
KrasS
Nice to see some people trying!
I'm very curious on this.. I'm used to dead on timing w/vsti's, so I guess when I fully go with a Pulsar setup, I won't be doing a lot of drum work in that environment.
I'll stick to Battery for that until something comes up if ever.
Keep those results comming!
- sinix
I'm very curious on this.. I'm used to dead on timing w/vsti's, so I guess when I fully go with a Pulsar setup, I won't be doing a lot of drum work in that environment.
I'll stick to Battery for that until something comes up if ever.
Keep those results comming!
- sinix
And in something like Cubase, you can account for this latency easily (with the delay/sample offset features e.g.) as long as it's *consistent*.
I've had it up to here (visual demo) with the erratic nature of the Pulsar virtual Midi ports. Can't adjust for something that's all over the map. Which is why I'm investing in a hardware midi interface as soon as fiscally viable.
I've had it up to here (visual demo) with the erratic nature of the Pulsar virtual Midi ports. Can't adjust for something that's all over the map. Which is why I'm investing in a hardware midi interface as soon as fiscally viable.