Re: MIDI over USB
On Wed, Jan 11, 2012 at 08:43:59AM +0100, pet...@schwertfisch.de wrote: Why is the extra -t slave needed to play audio tracks when the sub-device (mmc) is in slave mode already? the -tslave (aka mmc control) in the player is to allow the stream to relocate. So it's needed. Without -tslave, the player will start synchornously (because the server will block it until all clients start) but won't know how to relocate. Is there other software from packages that can be controlled this way (start, stop, relocate)? audio/lmms is supposed to support mmc, but I've never used it this way. Note that mmc is only necessary to relocate. If you only need the program to start and stay in sync, any app using a server sub-device with -tslave should work. Also, when using your setup and leaving out the -t slave the track can be started from midish using the p command, but it only plays for a second or so and then stops. $ aucat -fsnd/0.mmc -qmidithru/0 -i song50.wav -d snd0: playing s16le,0:1,44100 snd0: block size is 480 frames, using 27 blocks starting device server relocated to 0 wav(wav0)/run: stopping snd0: closing device short answer: - if mmc is required, both -qport and -tslave are needed - else, if -qport is required, mmc should be disabled in midish long answer: Even if -tslave is missing, aucat uses mmc internally (because code is simpler this way), so mmc is not 100% disabled when -tslave is missing. In the above case, midish sends the stop - relocate - start sequence, and aucat interprets it, but only partially. There's no extra code to filter mmc out when -tslave is missing (which would be cleaner). -- Alexandre
Re: MIDI over USB
Alexandre Ratchov a...@caoua.org wrote: I use OpenBSD to record music (audio and midi, combined), with the following hardware: - a Roland XV-2020 syth module (umidi) - a Behringer BCF-2000 control surface (umidi) - a Studiologic SL-900 midi keyboard - a ESI Julia card (envy) - a 1.8GHz Pentium 4 with 256MB of RAM - an analog mixer with mic-preamp and reverb I use midish as the main sequencer. MIDI parts (ie the syth) are recorded/played as simple tracks in midish. Audio tracks are simple wav files handled by an aucat slave process controlled by midish. I.e. midish issues all start/stop/relocate commands while sndiod keeps the whole thing synchronized using MTC/MMC. Additionnaly, I create a dedicated mixer track in midish where I record volume automation for the audio tracks played with aucat. Once everything sounds ok, I record the mix of synth tracks into a single wav file and I mix all audio tracks together to get the final mix into a single wav file that I compress with oggenc or lame. I don't use softsynths very often, but if I do, I use a midi thru box (additional -M option to sndiod) to make it look like a midi device so midish can use it. I record the softsynth output with -mmon option of sndiod. I don't edit tweak the music off-line too much since I consider that I should at least be able to properly play the music I'm trying to record... To summarize: # the server setup sndiod_flags=-M -z480 -b960 -frsnd/0 -r48000 -sdefault -tslave -smmc # command to play/record audio tracks aucat -fsnd/0.mmc -qmidithru/0 -tslave -r48000 -i track1.wav ... Why is the extra -t slave needed to play audio tracks when the sub-device (mmc) is in slave mode already? Is there other software from packages that can be controlled this way (start, stop, relocate)? Also, when using your setup and leaving out the -t slave the track can be started from midish using the p command, but it only plays for a second or so and then stops. $ aucat -fsnd/0.mmc -qmidithru/0 -i song50.wav -d snd0: playing s16le,0:1,44100 snd0: block size is 480 frames, using 27 blocks starting device server relocated to 0 wav(wav0)/run: stopping snd0: closing device Regards, Dirk # midish configuration dnew 0 rmidi:3 rw # synth dnew 1 rmidi:2 ro # keyboard dnew 2 rmidi:1 rw # control surface dnew 3 midithru/0 wo# slave aucat wav player dnew 4 snd/0 rw # sndiod dmtcrx 4 # use dev. 4 as MTC clock source Ah.. last point, not necessary, but I build sndiod with COPTS='-DADATA_BITS=24' to get end-to-end 24-bit precision. HTH -- Alexandre
Re: MIDI over USB
On Sat, Dec 31, 2011 at 04:44:19PM +0100, Jan Stary wrote: The manual of the MIDI keyboard says: When using USB cable to connect UF keyboard to computer music system, you must install the UF driver to the computer; otherwise the system will not accept the device. So, does Dec 31 15:11:04 box /bsd: ugen0 at uhub1 port 1 vendor 0x7104 product 0x2202 rev 1.00/1.00 addr 2 meanly that my device (CME UF6) is not USB class compliant, and therefore not supported by the umidi driver? IIRC, certain devices use standard midi/usb messages, but they hide the fact that they use the same message format as class compliant ones to avoid triggering a bug in (very) old windows versions. you can try to guess how your device works and if possible add a quirk to the umidi(4) driver, as follows: - figure out which usb endpoints appear to work, run: cat -u /dev/ugen0.N | hexdump -e '1/1 %02x\n' and play something on the keyboard until it prints 4-byte messages, try it for N = 1..15 - add the device to /usr/src/sys/dev/usb/usbdevs, run make in the same directory to update .h files (keep strings short as they are for other devices). - add the corresponding fixed endpoint quirk in umidi_quirks.c probably one similar to the UM-1 one. Drop me a e-mail if it works and/or you have any questions. Good luck -- Alexandre
Re: MIDI over USB
On Sat, Dec 31, 2011 at 02:23:25PM +0100, Robert wrote: The question is rather what you are going to do next. I tried to set up some software environment (synths, sequencer, effects etc.) under OpenBSD, but I run into a lot of issues since many tools are unfortunately Linux-specific, i.e. not usable without a lot of source code changes (if at all). So I ended up using a dedicated Linux machine for this. (I'm not talking about just recording some MIDI events, but rather a full set of tools such as e.g. www.64studio.com provides) If someone had a better experience, please post your setup! I use OpenBSD to record music (audio and midi, combined), with the following hardware: - a Roland XV-2020 syth module (umidi) - a Behringer BCF-2000 control surface (umidi) - a Studiologic SL-900 midi keyboard - a ESI Julia card (envy) - a 1.8GHz Pentium 4 with 256MB of RAM - an analog mixer with mic-preamp and reverb I use midish as the main sequencer. MIDI parts (ie the syth) are recorded/played as simple tracks in midish. Audio tracks are simple wav files handled by an aucat slave process controlled by midish. I.e. midish issues all start/stop/relocate commands while sndiod keeps the whole thing synchronized using MTC/MMC. Additionnaly, I create a dedicated mixer track in midish where I record volume automation for the audio tracks played with aucat. Once everything sounds ok, I record the mix of synth tracks into a single wav file and I mix all audio tracks together to get the final mix into a single wav file that I compress with oggenc or lame. I don't use softsynths very often, but if I do, I use a midi thru box (additional -M option to sndiod) to make it look like a midi device so midish can use it. I record the softsynth output with -mmon option of sndiod. I don't edit tweak the music off-line too much since I consider that I should at least be able to properly play the music I'm trying to record... To summarize: # the server setup sndiod_flags=-M -z480 -b960 -frsnd/0 -r48000 -sdefault -tslave -smmc # command to play/record audio tracks aucat -fsnd/0.mmc -qmidithru/0 -tslave -r48000 -i track1.wav ... # midish configuration dnew 0 rmidi:3 rw # synth dnew 1 rmidi:2 ro # keyboard dnew 2 rmidi:1 rw # control surface dnew 3 midithru/0 wo # slave aucat wav player dnew 4 snd/0 rw # sndiod dmtcrx 4# use dev. 4 as MTC clock source Ah.. last point, not necessary, but I build sndiod with COPTS='-DADATA_BITS=24' to get end-to-end 24-bit precision. HTH -- Alexandre
Re: MIDI over USB
On Jan 02 11:31:44, Alexandre Ratchov wrote:
On Sat, Dec 31, 2011 at 04:44:19PM +0100, Jan Stary wrote:
The manual of the MIDI keyboard says:
When using USB cable to connect UF keyboard to computer
music system, you must install the UF driver to the computer;
otherwise the system will not accept the device.
So, does
Dec 31 15:11:04 box /bsd: ugen0 at uhub1 port 1 vendor 0x7104 product
0x2202 rev 1.00/1.00 addr 2
meanly that my device (CME UF6) is not USB class compliant,
and therefore not supported by the umidi driver?
IIRC, certain devices use standard midi/usb messages, but they hide
the fact that they use the same message format as class compliant ones
to avoid triggering a bug in (very) old windows versions.
you can try to guess how your device works and if possible add a quirk
to the umidi(4) driver, as follows:
- figure out which usb endpoints appear to work, run:
cat -u /dev/ugen0.N | hexdump -e '1/1 %02x\n'
and play something on the keyboard until it prints 4-byte messages,
try it for N = 1..15
ugen0 at uhub1 port 1 vendor 0x7104 product 0x2202 rev 1.00/1.00 addr 2
$ cat -u /dev/ugen0.00
cat: /dev/ugen0.00: Operation not supported by device
$ cat -u /dev/ugen0.01
^C
$ cat /dev/ugen0.02
cat: /dev/ugen0.02: Input/output error
$ cat /dev/ugen0.03
cat: /dev/ugen0.03: Device not configured
$ cat /dev/ugen0.04
cat: /dev/ugen0.04: Device not configured
etc. So the device seems to be /dev/ugen0.01; however,
'cat -u /dev/ugen0.01' produces nothing when I play.
What does that mean?
- add the device to /usr/src/sys/dev/usb/usbdevs, run make in the
same directory to update .h files (keep strings short as they are
for other devices).
- add the corresponding fixed endpoint quirk in umidi_quirks.c
probably one similar to the UM-1 one.
This is what I did:
Index: umidi_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/umidi_quirks.c,v
retrieving revision 1.9
diff -u -p -r1.9 umidi_quirks.c
--- umidi_quirks.c 26 Jun 2008 05:42:19 - 1.9
+++ umidi_quirks.c 2 Jan 2012 19:45:26 -
@@ -338,6 +338,20 @@ UMQ_DEF(ROLAND, ROLAND_UA700, 3) = {
UMQ_TERMINATOR
};
+/*
+ * CME UF6
+ */
+UMQ_FIXED_EP_DEF(CME, CME_UF6, 2, 1, 1) = {
+ /* out */
+ { 0, 1 },
+ /* in */
+ { 1, 1 }
+};
+
+UMQ_DEF(CME, CME_UF6, 2) = {
+ UMQ_FIXED_EP_REG(CME, CME_UF6, 2),
+ UMQ_TERMINATOR
+};
/*
* quirk list
@@ -361,6 +375,7 @@ struct umidi_quirk umidi_quirklist[] = {
UMQ_REG(ROLAND, ROLAND_SD20, 0),
UMQ_REG(ROLAND, ROLAND_SD80, 0),
UMQ_REG(ROLAND, ROLAND_UA700, 3),
+ UMQ_REG(CME, CME_UF6, 2),
UMQ_TERMINATOR
};
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.567
diff -u -p -r1.567 usbdevs
--- usbdevs 1 Dec 2011 22:49:26 - 1.567
+++ usbdevs 2 Jan 2012 19:45:46 -
@@ -606,6 +606,7 @@ vendor ZINWELL 0x5a57 Zinwell
vendor SITECOM 0x6189 Sitecom
vendor ARKMICRO0x6547 Arkmicro
vendor 3COM2 0x6891 3Com
+vendor CME 0x7104 CME
vendor EDIMAX 0x7392 EDIMAX
vendor INTEL 0x8086 Intel
vendor INTEL2 0x8087 Intel
@@ -1192,6 +1193,9 @@ product CISCOLINKSYS WUSBF54G 0x0024 WUS
product CISCOLINKSYS WUSB200 0x0028 WUSB200
product CISCOLINKSYS2 RT3070 0x4001 RT3070
product CISCOLINKSYS3 RT3070 0x0101 RT3070
+
+/* CME products */
+product CME UF60x2202 UF6
I upgraded to current, cvs up'd, made the above edits, make in usb,
and recompiled the kernel.
Now the device shows up as
ugen0 at uhub1 port 1 vendor 0x7104 product 0x2202 rev 1.00/1.00 addr 2
but otherwise behaves the same: the only sensible dvice seems to be
ugen0.01, but playing the keyboard produces no output in cat -u.
Note that the umidi quirks are a blind copy of the Roland UM-1.
I don;t really know what USB 'quirks' are and I would like to
ask you for more guidance on what to try. Are the pairs in
/* out */
{ 0, 1 },
supposed to correspond to ugenX.Y ?
Thank you for your time
Jan
OpenBSD 5.0-current (GENERIC) #0: Mon Jan 2 21:06:24 CET 2012
r...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC
RTC BIOS diagnostic error 80clock_battery
real mem = 1054593024 (1005MB)
avail mem = 1012461568 (965MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe4410 (25 entries)
bios0: vendor Intel Corp. version MOPNV10J.86A.0175.2010.0308.0620 date
03/08/2010
bios0: Intel Corporation D510MO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET SSDT
acpi0: wakeup devices SLPB(S4) PS2M(S4) PS2K(S4) UAR1(S4) UAR2(S4) P32_(S4)
ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4)
Re: MIDI over USB
On Jan 02 21:29:44, Jan Stary wrote: I upgraded to current, cvs up'd, made the above edits, make in usb, and recompiled the kernel. Now the device shows up as ugen0 at uhub1 port 1 vendor 0x7104 product 0x2202 rev 1.00/1.00 addr 2 I mean ugen0 at uhub1 port 1 CME UF6 rev 1.00/1.00 addr 2 of course (see the dmesg); sorry for the confusion. Jan
Re: MIDI over USB
On Dec 31 22:35:58, Bryan Linton wrote: On 2011-12-31 16:44:19, Jan Stary h...@stare.cz wrote: The manual of the MIDI keyboard says: When using USB cable to connect UF keyboard to computer music system, you must install the UF driver to the computer; otherwise the system will not accept the device. So, does Dec 31 15:11:04 box /bsd: ugen0 at uhub1 port 1 vendor 0x7104 product 0x2202 rev 1.00/1.00 addr 2 meanly that my device (CME UF6) is not USB class compliant, and therefore not supported by the umidi driver? Jan Does your keyboard have any way to toggle class compliance? No. Several years ago I posted a message to the lists that my USB MIDI keyboard wasn't recognized. ugen1 at uhub3 port 1 Roland Roland Digital Piano rev 1.10/1.00 addr 2 I recieved a private reply from one of the developers who pointed out that my particular keyboard has two modes of operation. Vendor mode, which was the default that didn't work. And generic mode, AKA class-compliant mode which did work by default. Yes, that's what umidi(4) says. Unfortunately, my keyboard (CME UF6) doesn't have a switch to specifically use a class compliant USB MIDI mode. umidi0 at uhub3 port 1 configuration 1 interface 0 Roland Roland Digital Piano rev 1.10/1.00 addr 2 umidi0: (Fixed Endpoint) umidi0: out=1, in=1 midi1 at umidi0: USB MIDI I/F The manual for my keyboard mentioned a way to change this setting. I briefly searched through the manual for your keyboard and couldn't find it explicitly mentioned. Hopefully there's some way to get it to work. I'm afraid this is the only advice I can offer, so if it doesn't have a way to toggle the USB-MIDI mode, I'm out of ideas. :( Good luck. Thanks Jan
MIDI over USB
So I bought me a MIDI keyboard to enter the MIDI world. My sound card does not have a MIDI input, so before I buy one that does, I am connecting the keyboard via USB, which seems to work fine in Protools and MacOS's GarageBand. Now I'm trying to use it under OpenBSD. Reading fag13#midi, in particular the dmesg example, makes me think that USB-connected MIDI components should be recognized. Am I missing something? Thank you for your time Jan
Re: MIDI over USB
On Dec 31 13:25:57, Jan Stary wrote: So I bought me a MIDI keyboard to enter the MIDI world. (It's a CME UF6) My sound card does not have a MIDI input, so before I buy one that does, I am connecting the keyboard via USB, which seems to work fine in Protools and MacOS's GarageBand. Now I'm trying to use it under OpenBSD. Reading fag13#midi, in particular the dmesg example, makes me think that USB-connected MIDI components should be recognized. Am I missing something? OpenBSD 5.0-current (GENERIC.MP) #155: Sat Dec 10 07:57:12 MST 2011 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80clock_battery real mem = 1054593024 (1005MB) avail mem = 1012428800 (965MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe4410 (25 entries) bios0: vendor Intel Corp. version MOPNV10J.86A.0175.2010.0308.0620 date 03/08/2010 bios0: Intel Corporation D510MO acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT acpi0: wakeup devices SLPB(S4) PS2M(S4) PS2K(S4) UAR1(S4) UAR2(S4) P32_(S4) ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AZAL(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.98 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG cpu0: 512KB 64b/line 8-way L2 cache cpu0: apic clock running at 168MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1683.35 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG cpu1: 512KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1683.36 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG cpu2: 512KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1683.35 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG cpu3: 512KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 5 (P32_) acpiprt1 at acpi0: bus 0 (PCI0) acpiprt2 at acpi0: bus 1 (PEX0) acpiprt3 at acpi0: bus 2 (PEX1) acpiprt4 at acpi0: bus 3 (PEX2) acpiprt5 at acpi0: bus 4 (PEX3) acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpicpu2 at acpi0: C1, PSS acpicpu3 at acpi0: C1, PSS acpibtn0 at acpi0: SLPB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Pineview DMI rev 0x02 vga1 at pci0 dev 2 function 0 Intel Pineview Video rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 8 int 16 drm0 at inteldrm0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x01: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800), apic 8 int 16, address 00:27:0e:07:09:9f rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x01: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x01: msi pci3 at ppb2 bus 3 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x01: msi pci4 at ppb3 bus 4 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x01: apic 8 int 23 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x01: apic 8 int 19 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x01: apic 8 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x01: apic 8 int 16 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x01: apic 8 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe1 pci5 at ppb4 bus 5 pcib0 at pci0 dev 31 function 0 Intel Tigerpoint LPC rev 0x01 ahci0 at pci0 dev 31 function 2 Intel 82801GR AHCI rev 0x01: msi, AHCI 1.1 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: ATA, WDC WD6400BPVT-0, 01.0 SCSI3 0/direct fixed naa.50014ee25979e46a sd0: 610480MB, 512 bytes/sector, 1250263728 sectors sd1 at scsibus0 targ 1 lun 0: ATA, WDC WD10TPVT-00H, 01.0 SCSI3 0/direct fixed naa.50014ee2aed8deca sd1: 953869MB, 512
Re: MIDI over USB
On Sat, 31 Dec 2011 13:25:57 +0100 Jan Stary h...@stare.cz wrote: Reading fag13#midi, in particular the dmesg example, makes me think that USB-connected MIDI components should be recognized. Am I missing something? I just tested - works fine [1]; just try a different port. Mine didn't work on the EHCI port [2], but on the add-in card with UHCI [3]. The question is rather what you are going to do next. I tried to set up some software environment (synths, sequencer, effects etc.) under OpenBSD, but I run into a lot of issues since many tools are unfortunately Linux-specific, i.e. not usable without a lot of source code changes (if at all). So I ended up using a dedicated Linux machine for this. (I'm not talking about just recording some MIDI events, but rather a full set of tools such as e.g. www.64studio.com provides) If someone had a better experience, please post your setup! kind regards, Robert [1] umidi0 at uhub3 port 1 configuration 1 interface 1 WORLDE WORLDE CONTROLLER rev 1.10/0.00 addr 2 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi0 at umidi0: USB MIDI I/F ugen1 at uhub3 port 1 configuration 1 WORLDE product 0x0201 rev 1.10/0.00 addr 2 [2] addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel (0x8086), rev 1.00 [3] addr 1: full speed, self powered, config 1, UHCI root hub(0x), VIA (0x1106), rev 1.00 port 1 addr 2: full speed, power 500 mA, config 1,product 0x0201 (0x0201), vendor 0x0218(0x0218), rev 0.00
Re: MIDI over USB
On Dec 31 14:23:25, Robert wrote: On Sat, 31 Dec 2011 13:25:57 +0100 Jan Stary h...@stare.cz wrote: Reading fag13#midi, in particular the dmesg example, makes me think that USB-connected MIDI components should be recognized. Am I missing something? I just tested - works fine [1]; just try a different port. Mine didn't work on the EHCI port [2], but on the add-in card with UHCI [3]. I tried all my USB ports now, with the same result: if I plug the USB cable in and then turn the keyboard on, nothing happens; if I turn the keyboard on and then plug the USB cable in, the following device appears: Dec 31 15:11:04 box /bsd: ugen0 at uhub1 port 1 vendor 0x7104 product 0x2202 rev 1.00/1.00 addr 2 The question is rather what you are going to do next. I tried to set up some software environment (synths, sequencer, effects etc.) under OpenBSD, but I run into a lot of issues since many tools are unfortunately Linux-specific, audio/midish Jan
Re: MIDI over USB
The manual of the MIDI keyboard says: When using USB cable to connect UF keyboard to computer music system, you must install the UF driver to the computer; otherwise the system will not accept the device. So, does Dec 31 15:11:04 box /bsd: ugen0 at uhub1 port 1 vendor 0x7104 product 0x2202 rev 1.00/1.00 addr 2 meanly that my device (CME UF6) is not USB class compliant, and therefore not supported by the umidi driver? Jan
