PortMidi clients and ALSA - comp.music.midi

Greetings, When csound runs, it uses PortMidi, and can connect from an ALSA midi-output-port with its -M 6 option. csound numbers the ports with non-ALSA numbers which can be seen with csound -M999 null.csd which causes csound to print a list of the valid output-ports: The available MIDI in devices are: 0: Midi Through Port-0 (ALSA) 1: Midi Through Port-1 (ALSA) 2: VirMIDI 1-0 (ALSA) 3: VirMIDI 1-1 (ALSA) 4: VirMIDI 1-2 (ALSA) 5: VirMIDI 1-3 (ALSA) 6: Keystation 49e MIDI 1 (ALSA) 7: ProKeys Sono 88 MIDI 1 (ALSA) 8: Output port (ALSA) *** PortMIDI: error: device number is out of range Is there a way of converting the ALSA numbers to csound's numbers ? They do seem to be in the same order, but is this reliable ? Can I, from within ALSA, get details of clients like this 130 ? After csound -M 8 genuine.csd then aconnect -oil shows: client 129: 'fluisynth pid=2952' [type=user] 0 'Input port ' 1 'Output port ' Connecting To: 130:17[real:0] but client 130 does not otherwise appear in aconnect -oil ! Also, that connection ( from 129:1 to 130:17[real:0] ) is not disconnected by aconnect -x ! Nothing resembling client 130 seems to appear in /dev/snd ... Attempts to connect to it: aconnect ProKeys 130:17 meet with: Connection failed (Operation not permitted) and aconnect -r ProKeys 130:17 gets a Usage: message. Is there an ALSA way of connecting to a client like 130 ? man aconnect says: The suffix flag [real:#] and [tick:#] mean the connection includes real-time and tick conversion on the listed queue, respectively. Are all PortMidi clients like this ? Regards, Peter -- Peter Billam www.pjb.com.au www.pjb.com.au/comp/contact.html

Peter Billam wrote: > Is there a way of converting the ALSA numbers to csound's numbers ? Have a look at csound's or PortMIDI's source code. > After csound -M 8 genuine.csd then aconnect -oil shows: > client 129: 'fluisynth pid=2952' [type=user] > 0 'Input port ' > 1 'Output port ' > Connecting To: 130:17[real:0] > but client 130 does not otherwise appear in aconnect -oil ! aconnect shows only clients that you are allowed to connect. PortMIDI is based on the Windows 3.1 MIDI API, which has only drivers and does not have the ability to allow applications to connect to each other. > Nothing resembling client 130 seems to appear in /dev/snd ... /proc/asound/seq/clients Regards, Clemens

In article <slrnk2rmv0.32d.peter@box8.pjb.com.au>, Peter Billam <contact.html@www.pjb.com.au> wrote: >Greetings, > >When csound runs, it uses PortMidi, and can connect from an ALSA >midi-output-port with its -M 6 option. csound numbers the >ports with non-ALSA numbers which can be seen with > csound -M999 null.csd >which causes csound to print a list of the valid output-ports: Maybe I'm missing something here, but I never use PortMIDI with Csound. HAve you tried the "-+rtmidi=alsa" option? It's always worked for me, at least to connect to VirMIDI and things. A typical (bash script) line is (with inessential bits omitted): csound -+rtaudio=alsa -+rtmidi=alsa -Mhw:2,0,0 -o dac $* where the "-Mhw..." corresponds to the appropriate entry in /dev/snd. I'm definitely not clear on your "client 130" problem. I've never hit anything like that. (The only "ProKeys" I've heard of is the M-Audio K/B which surely doesn't need PortMIDI either.) (BTW, what's your "null.csd"? I tried to reproduce your command line above, and only get errors. Using a working csd with "-M999" doesn't give me any listing either.) Cheers, -- Pete -- -- ============================================================================ The address in the header is a Spam Bucket -- don't bother replying to it... (If you do need to email, replace the account name with my true name.)

On 2012-08-18, Pete <neverland@GOODEVEca.net> wrote: > Maybe I'm missing something here, but I never use PortMIDI with > Csound. Have you tried the "-+rtmidi=alsa" option? It's always > worked for me, at least to connect to VirMIDI and things. > A typical (bash script) line is (with inessential bits omitted): > csound -+rtaudio=alsa -+rtmidi=alsa -Mhw:2,0,0 -o dac $* > where the "-Mhw..." corresponds to the appropriate entry in /dev/snd. My problem with that is that I want to be able to connect from non-hardware clients. I would have thought that -+rtmidi=alsa should create an alsa client, but no. > I'm definitely not clear on your "client 130" problem. I've > never hit anything like that. (The only "ProKeys" I've heard of > is the M-Audio K/B which surely doesn't need PortMIDI either.) Yes, it is one of those. I find the -Mhw:2,0,0 encyphering task no simpler than the -M8 encyphering task, and -M8 can connect from alsa clients that aren't hardware. At the moment I'm running (forking) a dummy client use MIDI::ALSA; MIDI::ALSA::client( $AlsaName, 1, 1, 0 ); foreach my $input (@Inputs) { my $rc = MIDI::ALSA::connectfrom( 0, $input ); # input port is 0 if (! $rc) { warn " warning: couldn't connect from $input\n"; } } while (1) { my @alsaevent = MIDI::ALSA::input(); MIDI::ALSA::output( @alsaevent ); } That's all :-) see: http://search.cpan.org/perldoc?MIDI::ALSA and then running csound -M999 null.csd and parsing its stderr for /Output port/ (giving e.g. 8) and then starting csound -M8 fluisynth.csd and it works :-) Or, I could parse /proc/asound/seq/clients though it doesn't contain the csound-numbers (but the clients _seem_ to be in the same order); or even both, hoping that one of them might work. > (BTW, what's your "null.csd"? I tried to reproduce your > command line above, and only get errors. Perhaps your null.csd is too empty ? My null.csd is: <CsoundSynthesizer> <CsOptions> -d -m0 -M99 -iadc -odac </CsOptions> <CsInstruments> sr = 44100 ksmps = 128 nchnls = 2 0dbfs = 1 instr 1 endin </CsInstruments> <CsScore> e </CsScore> </CsoundSynthesizer> > Using a working csd with "-M999" doesn't give me any listing either. That surprises me... Jim Aikin in "Csound Power" p.250 says: However, the Csound implementation of ALSA MIDI uses the "raw" sequencer interface, so Linux users may need to load the vir-midi kernel module. which of course I'm loading anyway (also, the Midi Through clients work just as well), and they always come up as the same csound-numbers on my machine which is convenient on my machine but totally unportable. Also, I want the client to be called fluisynth not Midi Through Port-0. man csound says: If using ALSA MIDI (-+rtmidi=alsa), devices are selected by name and not number. So, you need to use an option like -M hw:CARD,DEVICE where CARD and DEVICE are the card and device numbers (e.g. -M hw:1,0). but their idea of selecting "by name" doesn't extend as far as: -M'Midi Through Port-0' or: -Mfluisynth so I'm not sure what names they're talking about. I'm on the csound mailing list, but I'm not sure it would be safe to suggest that -+rtmidi=alsa should actually start an alsa client; I know they're very dedicated to backward-compatibility. I haven't checked out the portmidi source yet; I just got back from http://2012.pycon-au.org/programme/ Peter -- Peter Billam www.pjb.com.au www.pjb.com.au/comp/contact.html

In article <slrnk316be.1tj.peter@box8.pjb.com.au>, Peter Billam <contact.html@www.pjb.com.au> wrote: > On 2012-08-18, Pete <neverland@GOODEVEca.net> wrote: > > Maybe I'm missing something here, but I never use PortMIDI with > > Csound. Have you tried the "-+rtmidi=alsa" option? > > My problem with that is that I want to be able to connect from > non-hardware clients. I would have thought that -+rtmidi=alsa > should create an alsa client, but no. That's sort of the function of ALSA Sequencer ports, isn't it? The way I understand it, ALSA ('Raw') MIDI only connects to drivers -- usually themselves connecting to hardware, but VirMIDI is a special case that straddles both Raw and Sequencer levels. And of course the ALSA drivers provide Sequencer level connections as well as the entries in /dev/snd and the "hw:n.n.n" names (bloody confusing...). Only the Sequencer ports make for easy interconnection (via aconnect). And if you look at fluidsynth (the stand-alone command-line app), it doesn't try to provide ports at the raw level either. Only if you use the "-m alsa_seq" option, do you see a Sequencer client in the aconnect list. So I guess what you're really looking for is a "-+rtmidi=alsa-seq" option in Csound. Seems that should be possible. > > I find the -Mhw:2,0,0 encyphering task > no simpler than the -M8 encyphering task, You and me both... (:-/) > and -M8 can connect from alsa clients that aren't hardware. OK -- it looks as if portmidi connects at the sequencer level. But surely you can still use VirMIDI to connect as you want? > > At the moment I'm running (forking) a dummy client > and then running csound -M999 null.csd and parsing its stderr > for /Output port/ (giving e.g. 8) and then starting > csound -M8 fluisynth.csd > and it works :-) Or, I could parse /proc/asound/seq/clients though > it doesn't contain the csound-numbers (but the clients _seem_ to be > in the same order); or even both, hoping that one of them might work. Seems unnecessary work... VirMIDI shows up in the list (doesn't it?) so just connect through that. > > > (BTW, what's your "null.csd"? I tried to reproduce your > > command line above, and only get errors. > > Perhaps your null.csd is too empty ? Definitely... (:-/) Wasn't sure how much was necessary. > > > Using a working csd with "-M999" doesn't give me any listing either. > That surprises me... It didn't me -- after I realized that I didn't even have the PortMIDI plugin installed! I couldn't use the Ubuntu supplied Csound because it was 64-bit; too much for my old slow machine, and I guess I never included it in my compilation because I knew I wasn't going to use it. I'm still setting everything up on my new laptop, but I have no problems with speed there (!) so I'm using the 5.17.6 distribution, and I'm seeing what you'd expect now. > > Jim Aikin in "Csound Power" p.250 says: > However, the Csound implementation of ALSA MIDI uses the "raw" > sequencer interface, so Linux users may need to load the vir-midi ^^^ I don't think he should have said "sequencer"...It's just raw MIDI bytes, unlike the structs passed around by Sequencer ports. > kernel module. > > man csound says: > If using ALSA MIDI (-+rtmidi=alsa), devices are selected by name and > not number. So, you need to use an option like -M hw:CARD,DEVICE > where CARD and DEVICE are the card and device numbers (e.g. -M hw:1,0). > but their idea of selecting "by name" doesn't extend as far as: > -M'Midi Through Port-0' > or: > -Mfluisynth > so I'm not sure what names they're talking about. I'm sure they mean that lovely string "hw:1.0.0"! (:-/) Yes, it would be great if there was some uniform way of relating names (as provided by the HW/Driver/Whatever) to the numbers used elsewhere. I guess the reason for the lack is that originally devides didn't supply any names. What's really annoying is that the ordering depends on random things like when you plugged your USB cord in, so you can't write a script that's guaranteed to work. Your observation about /proc/asound/seq/clients might be useful. Should be possible to write a small script that takes a name and returns its list position number. I'd say it's a pretty solid bet that portmidi scans that list (or an equivalent) to get its numbers too. -- Pete -- -- ============================================================================ The address in the header is a Spam Bucket -- don't bother replying to it... (If you do need to email, replace the account name with my true name.)

On 2012-08-21, Pete <neverland@GoodeveCa.net> wrote: > So I guess what you're really looking for is a "-+rtmidi=alsa-seq" > option in Csound. Seems that should be possible. That seems to be going well so far... I wrote on the csound list: >Csound's alsa midi support isn't very helpful... -+rtmidi=asla >doesn't create an alsa client, and so doesn't show up with > aconnect -oil and can't be connected to using aconnect >or disconnected from using aconnect -d or aconnect -x or >played to with aplaymidi -p or midikbd -o or midiedit or >midifade -o or connected from more than one source, etc etc. >I know csound can be run initially with a -M999 option, and >its STDERR parsed for lines /^\s*(\d+):\s+(.+)\s+\(ALSA/ >, and then re-run with (one of) the desired numbers, but >that's slow and messy. Csound can be started up connecting >from some hardcoded number but that's very unportable. >It would be more useful, and look less clunky, if csound could >start a proper ALSA client. It's not much code; this example >( see: http://search.cpan.org/perldoc?MIDI::ALSA ) is in Perl: > use MIDI::ALSA; > MIDI::ALSA::client( "csound pid=$$", 1, 1, 0 ); > foreach my $input (@Inputs) { > MIDI::ALSA::connectfrom( 0, $input ) > or warn(" warning: couldn't connect from $input\n"); > } > while (1) { > my @alsaevent = MIDI::ALSA::input(); > do_something( @alsaevent ); > } >The corresponding C routines are in > http://cpansearch.perl.org/src/PJB/MIDI-ALSA-1.14/ALSA.xs >or within > http://www.pjb.com.au/comp/lua/midialsa-1.15.tar.gz >I'd like to suggest that -+rtmidi=alsa should create a proper >ALSA client. If that's not possible for backward-compatibility >reasons, I'd like to suggest a new -+rtmidi=alsaseq option. >Apologies if it's been raised before and rejected... I only now notice I shortened alsa-seq to alsaseq, oh well, it still works. And Tito Latini replied: >It is simple and useful, I think that this evening it will >be in git (before the freeze) otherwise, if I'll have other >problems, it is deferred to the next week. I wrote: >Wonderful news, that would be most welcome :-) >It has implications for -M, because those arguments could be >strings, and could even be multiple, e.g.: > -M ProKeys > -M ProKeys,Keystation > -M ProKeys,Keystation,14:1 >I hope this will be OK ? You call parse_address() once your >client is running, and it converts each string to an addr struct >(addr->client and addr->port) in a way that's compatible with >everything else in alsa-midi, e.g. > aconnect ProKeys Roland > aplaymidi -p TiM x.mid > midichord -Q -f 0,1 -a 4,5 -i 14:0,Pro -o 14:1,TiMidity which crossed with Tito's email: >I have the 50% of the code but I cannot continue today. >I'll conclude it during my breaks the next week. >An example of the interface is > csound -+rtmidi=alsaseq -M14,16 -Q128,129 >Read from the clients 14, 16 and write to the clients 128 and 129. >The default for the client name is "Csound" but it is setable with > -+alsaseq_client=[client_name] >that it is coherent with > -+jack_client=[client_name] At that stage, alsaseq_client does look better than alsa-seq_client. Tito followed up: >update: it remains only the parser for the in/out strings >and `-+alsaseq_client' option. It will be possible: > csound -+rtmidi=alsaseq -M 20,"MIDI Controller:1" \ > -Q WashingMachine:2,128:1,Curiosity So, so far so good :-) Strangely, for me fluidsynth gives a latency of >100mS, similar to TiMidity, whereas my csound script with fluidEngine must be around 25mS; it makes all the difference. Maybe fluidEngine implements less controllers? I think it does 0,1,10,11,64, perhaps a few others. Regards, Peter -- Peter Billam www.pjb.com.au www.pjb.com.au/comp/contact.html

In article <slrnk3gng4.2hn.peter@box8.pjb.com.au>, Peter Billam <contact.html@www.pjb.com.au> wrote: >On 2012-08-21, Pete <neverland@GoodeveCa.net> wrote: >> So I guess what you're really looking for is a "-+rtmidi=alsa-seq" >> option in Csound. Seems that should be possible. > >That seems to be going well so far... I wrote on the csound list: > [....] >So, so far so good :-) Yep -- sounds good! I really have to join the Csound list myself, but I've been finding the Haiku lists enough to plow through at the moment... I was porting Csound 5.17.6 to Haiku, and had got to the point of playing live audio and reading MIDI before my drive crashed! Fortunately I was eventually able to nibble back nearly everything from the crashed drive, including my Csound work, but I haven't got back to it yet. When I do, I'll have to sit on the Csound list to get the Haiku code integrated! > >Strangely, for me fluidsynth gives a latency of >100mS, similar to >TiMidity, whereas my csound script with fluidEngine must be around 25mS; >it makes all the difference. Maybe fluidEngine implements less >controllers? I think it does 0,1,10,11,64, perhaps a few others. > My guess would be (default) buffer size. I haven't played with fluidsynth on my new machine yet, but I did notice that Csound (not using fluidsynth) is delightfully responsive. On my old machine I remember latency being adequate, but I don't recall if I tweaked buffers or anything. Did have to run sudo, though, to get glitch free sound. Not a problem on my laptop... multicore is nice! I'll check my old box again when I get a chance. -- Pete -- -- ============================================================================ The address in the header is a Spam Bucket -- replies will not be seen... (If you do need to email, replace the account name with my true name.) ============================================================================