Patches and discussion for Ensoniq VFX family group photo

Yahoo Groups archive

Patches and discussion for Ensoniq VFX family

Index last updated: 2026-04-29 00:03 UTC

Thread

Re: [Ensoniq-VFX-SD] Beware cheap chinese USB MID I cables onebay...

Re: [Ensoniq-VFX-SD] Beware cheap chinese USB MID I cables onebay...

2008-06-21 by Claus

Hi and thanks :)


I've made a VST-synth in Synthedit. I needed to get the aftertouch modulation to work. I have a microX hooked up to the PC I make it on. First surprise: NO aftertouch comming out of the microX. (Damn, I should have read the feature list..) So I turned to my trusty VFX and hooked it up.

By using the MIDI monitor module in SE, I needed to see exactly WHAT came through and what might not. Of course it worked with the VFX (Channel Pressure anyway, seems like Synthedit don't know Poly Pressure, but I really don't know, 'cause I haven't used it in my VST-plugin)


Long story short: I can see no Running Status or Active Sensing from the VFX at all :) As a test back then I tried hooking up my RD-170 (Roland E-Piano): I wasn't even able to see the keys I pressed because the running status bytes were so many!! By looking in the MIDI implementation chart, one can see that active sensing is not used in the VFX. It's a little more shady with Runnung Status as it's not mentioned. What IS mentioned though is that the VFX always sends NOTE OFF with a velocity of 64 when transmitting, when on the VFX recieving note offs there is a "X" which means it doesn't recognize NOTE OFF??? THAT makes me think....!


My conclusion would lead to Your own actually: Get a branded MIDI interface. Sounds like the chinese one You got doesn't 'tick'. What if You hook up to another keyboard? Works?


You could try Synthedits MIDI monitor Yourself, dead easy to use:

www.synthedit.com

They call it shareware, even though it has no nagscreens and so. OK, when You save a SE plug as a DLL to be used outside SE's environment there will be, and the shareware version is limited to two analogue outputs. You'll get 12 (6 L+R sets or iow. 6 different 2-channel soundcards(!) if one can cram it in their system!) in the commercial version of SE!


And last, but not least, You can check out my "C'Ultra 1" on:

www.myspace.com/audiosaucer.

There are a few soundexamples there. Btw. never mind the 'bad' soundquality of the myspace player - At least the treble gets smashed :(


Regards,

Claus, DK


-----Original Message-----

From: steve@...

Sent: Saturday, June 21, 2008 5:28 AM -07:00

To: Ensoniq-VFX-SD@yahoogroups.com

Subject: [Ensoniq-VFX-SD] Beware cheap chinese USB MIDI cables onebay...


On Sat, Jun 21, 2008 at 03:11:23AM +0000, Claus wrote:

> Hi Steve :)

>

> I´ve been using a Winman 1x1 (ISA back then!) with no

> problems. Midiman BiPort 2x4s (COM port) on Win98se with NO

> problems. For the last year or so, a MidiSport 8x8 (USB on 98se(!!)

> is running. No problem either. I've also tried the MIDI I/O on the

> Evolution UC33e controller and the MIDI I/O on a Terratec Phase

> 22. All working.


I've used a few working interfaces over the years, too. You mention

all brand name stuff, many that shipped with their own drivers.


I should be clear: I'm not talking about brand name midi interfaces

that just happen to be made in China. They're likely as good as the

name on them and the company standing behind them.


I'm talking about a no-name, generic USB-MIDI cable from ebay, that in

fact I realize I'm only assuming was made in China.


Speaking as a driver writer (but, so far, not a MIDI driver writer),

sometimes hardware has bugs in it that must be worked around. My

theory is that this cheap, no-name cable "stole" the circuitry /

silicon from a slightly buggy version of the UNO, and changed the USB

ID for the device which means the driver that works OK with a real UNO

can't recognize that it has to compensate for a hardware bug.


(If you don't think they can easily steal things like circuit board

artwork and silicon, read up on counterfiet Cisco hardware someday!)


> So I'm really wondering what Your problem might be. Maybe I'm wrong,

> but to my knowledge, VFXs don't use running status. Roland does, as

> one of the only ones getting to my mind from back then.


If it's true that the VFX doesn't use running status, that throws a

big wrench into my theory. I looked at a different interface with my

VFX and Midi-Ox, and I don't see running status. BUT I have a feeling

that the windows midi driver API has the driver hide received running

status from the applications, so midi-ox wouldn't know if running

status came in or not.


If I get time, I'll hook up the oscilloscope and find out for certain!

:-)


(You're not by any chance confusing running status with active

sensing, are you? I know nearly nobody used active sensing.)


> To me it really sounds like a 'bad' USB port or something along that

> line. Which might include bad drivers. The BiPort 2x4s as an example

> runs way better with v1.02 than the newest avaiable drivers (1.05 I

> think, allthough discontinued). Have You tried that? It MIGHT

>; help.


This is one of those devices that doesn't come with drivers, instead

uses the "class" drivers that ship with your OS. So far I've used Mac

OS X Leopard, and Windows XP (SP2 I think, but I haven't paid too much

attention to detail there); both machines using USB ports that have no

problem with other things like thumb drives. I also used a MidiMan

Oxygen 8 on the mac a little while back. I can't say for sure it was

the same port, because I have two USB ports.


> Else I really would suggest the 8x8s (or similar), since it:

> Brings LOTS of I/O, works as a MIDI-patchbay. AND can be used

>; without the computer :)) (OK, pricey, but really nice!)


I have quite a few examples of midi interfaces around here; I think I

even still have one to connect to my amiga around somewhere! While

I've had one in particular be a bit flakey (MOTU PC midi flyer,

parallel port connection, I think it was interrupt conflicts or

something that caused flakeyness), all the others I've tried have

basically worked. Never had a problem like this before.


The object of this purchase was a simple, inexpensive midi interface I

can toss in the laptop bag. $20 seemed like a "what have I got to

lose" price -- the answer was I've got $20 to lose, of course. $40 +

tax / shipping / etc. for a brand name interface seemed a little high

at the time. Not now, though!


> One last (SIMPLE!) suggestion, as I had this problem once: Have You

> tried spraying the MIDI I/Os on the VFX with elctronic-cleaner? That

> MIGHT help too.


I use the VFX-SD midi out all the time to control a Roland JV-1080.

And I hooked it up to the midi in on my Emu-1212 just to check for

certain (same win XP system I tested the USB interface on). NO

dropped notes with that. So, I think the electrical connection is

fine.


> You're on XP?


As well as OS X Leopard and various Linux systems; haven't done MIDI

on any of them for a while. I mostly use MIDI only for live playing

and VFX-SD sequencing; I just record audio when I use a computer.


But, anyway, thanks for your input on this, Claus!


--> Steve


--

Steve Wahl steve@...


"'No Child Left Behind' -- Think about those words for a second. How

else do you not leave a child behind unless you hold everyone else

back with him?"

-- Someone named "Geoffrey" on Slashdot

Re: [Ensoniq-VFX-SD] Beware cheap chinese USB MIDI cables onebay...

2008-06-22 by Steve Wahl

Claus,

> As a test back then I tried hooking up my RD-170
> (Roland E-Piano): I wasn't even able to see the keys I pressed
> because the running status bytes were so many!!

I think we have a fundamental "impedance mismatch" here.  What you
think is running status is not what I think is running status.

Your version of running status seems to create more bytes in the midi
stream, where the concept I'm talking about creates fewer bytes.  Can
you give me byte values that are sent that would explain what you are
talking about, or point to some documentation?

What I believe is running status I find described in an old document
called usenet midi primer:

http://www.harmony-central.com/MIDI/Doc/primer.txt

Search for running status, the second occurance you find this:

       For all of these messages, a convention called the "running status
       byte" may be used.  If the transmitter wishes to send another message
       of the same type on the same channel, thus the same status byte, the
       status byte need not be resent.

That's what I'm talking about.  It means that the two hex byte
sequences "90 45 40 90 47 42" and "90 45 40 47 42" mean the same thing
(two note on messages); the second string can leave out the second
"90" note-on status byte because it is implied by what's called the
running status byte convention.

--> Steve

-- 
Steve Wahl    steve@...

Creativity is allowing yourself to make mistakes. 
Art is knowing which ones to keep.    -- Scott Adams

Re: [Ensoniq-VFX-SD] Beware cheap chinese USB MID I cables onebay...

2008-06-22 by Claus

OOps!


Yes, It's Active Sensing generating lots of data - sorry :(

But did You try the suggestion(s)?


Regards,

Claus, DK


-----Original Message-----

From: steve@...

Sent: Sunday, June 22, 2008 2:54 AM -07:00

To: Ensoniq-VFX-SD@yahoogroups.com

Subject: [Ensoniq-VFX-SD] Beware cheap chinese USB MIDI cables onebay...


Claus,


> As a test back then I tried hooking up my RD-170

> (Roland E-Piano): I wasn't even able to see the keys I pressed

> because the running status bytes were so many!!


I think we have a fundamental "impedance mismatch" here. What you

think is running status is not what I think is running status.


Your version of running status seems to create more bytes in the midi

stream, where the concept I'm talking about creates fewer bytes. Can

you give me byte values that are sent that would explain what you are

talking about, or point to some documentation?


What I believe is running status I find described in an old document

called usenet midi primer:


http://www.harmony-central.com/MIDI/Doc/primer.txt


Search for running status, the second occurance you find this:


For all of these messages, a convention called the "running status

byte" may be used. If the transmitter wishes to send another message

of the same type on the same channel, thus the same status byte, the

status byte need not be resent.


That's what I'm talking about. It means that the two hex byte

sequences "90 45 40 90 47 42" and "90 45 40 47 42" mean the same thing

(two note on messages); the second string can leave out the second

"90" note-on status byte because it is implied by what's called the

running status byte convention.


--> Steve


--

Steve Wahl steve@...


Creativity is allowing yourself to make mistakes.

Art is knowing which ones to keep. -- Scott Adams


Re: Re: [Ensoniq-VFX-SD] Beware cheap chinese USB MIDI cables onebay...

2008-06-22 by Neil Wakeling

I think you are referring to "active sensing" where a synth or module sends out a stream of bytes to say "I'm still here!"

I don't know if many modern units stil ldo it but certainly i believe older synths did it or expected it.

try http://www.borg.com/%7Ejglatt/tech/midispec/sense.htm
http://www.planetoftunes.com/sequence/activesense.html

cheers
neil

Steve Wahl wrote:
Show quoted textHide quoted text

Claus,

> As a test back then I tried hooking up my RD-170
> (Roland E-Piano): I wasn't even able to see the keys I pressed
> because the running status bytes were so many!!

I think we have a fundamental "impedance mismatch" here. What you
think is running status is not what I think is running status.

Your version of running status seems to create more bytes in the midi
stream, where the concept I'm talking about creates fewer bytes. Can
you give me byte values that are sent that would explain what you are
talking about, or point to some documentation?

What I believe is running status I find described in an old document
called usenet midi primer:

http://www.harmony-central.com/MIDI/Doc/primer.txt

Search for running status, the second occurance you find this:

For all of these messages, a convention called the "running status
byte" may be used. If the transmitter wishes to send another message
of the same type on the same channel, thus the same status byte, the
status byte need not be resent.

That's what I'm talking about. It means that the two hex byte
sequences "90 45 40 90 47 42" and "90 45 40 47 42" mean the same thing
(two note on messages); the second string can leave out the second
"90" note-on status byte because it is implied by what's called the
running status byte convention.

--> Steve

Re: [Ensoniq-VFX-SD] Beware cheap chinese USB MID I cables onebay...

2008-06-23 by Claus

Thank You :) Yes, I had them opposite :-/

I never had to think about it in my setup, so it was a long time...:)


Regards,

Claus, DK




-----Original Message-----

From: neil@dancing-dog.co.uk

Sent: Sunday, June 22, 2008 11:20 AM -07:00

To: Ensoniq-VFX-SD@yahoogroups.com

Subject: Re: [Ensoniq-VFX-SD] Beware cheap chinese USB MIDI cables onebay...


I think you are referring to "active sensing" where a synth or module

sends out a stream of bytes to say "I'm still here!"


I don't know if many modern units stil ldo it but certainly i believe

older synths did it or expected it.


try http://www.borg.com/%7Ejglatt/tech/midispec/sense.htm

http://www.planetoftunes.com/sequence/activesense.html


cheers

neil


Steve Wahl wrote:

>

> Claus,

>

> > As a test back then I tried hooking up my RD-170

>; > (Roland E-Piano): I wasn't even able to see the keys I pressed

> > because the running status bytes were so many!!

>

> I think we have a fundamental "impedance mismatch" here. What you

> think is running status is not what I think is running status.

>

> Your version of running status seems to create more bytes in the midi

> stream, where the concept I'm talking about creates fewer bytes. Can

> you give me byte values that are sent that would explain what you are

> talking about, or point to some documentation?

>

> What I believe is running status I find described in an old document

> called usenet midi primer:

>

> http://www.harmony-central.com/MIDI/Doc/primer.txt

>

>

> Search for running status, the second occurance you find this:

>

> For all of these messages, a convention called the "running status

> byte" may be used. If the transmitter wishes to send another message

> of the same type on the same channel, thus the same status byte, the

> status byte need not be resent.

>

> That's what I'm talking about. It means that the two hex byte

>; sequences "90 45 40 90 47 42" and "90 45 40 47 42" mean the same thing

> (two note on messages); the second string can leave out the second

> "90" note-on status byte because it is implied by what's called the

>; running status byte convention.

>

> --> Steve

>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.