Hi all, I was wondering the following:
In my app (RTMix) I will be soon implementing multiple midi-input device
opens, so that the app can be controlled from as many of the midi
controllers simultaneously as possible. One way of devising this was to
design a separate thread for every open device (using raw midi /dev/midi
etc., although I will be re-implementing that to use ALSA devices
directly). However, this might not be the most elegant way of doing
this, so what I was wondering is how does the /dev/sequencer correspond
to this issue? I mean, does it work the same way like addressing the raw
midi ports, are the message formats the same, and most importantly does
one SINGULAR /dev/sequencer encompass all of the midi ports that are
currently available?
I would greatly appreciate any help on this issue, as well as some code
examples. Thank you! Sincerely,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico
[ My apologies if you see this more than once ... --jl ]
Hi everyone,
I've spent the last few months editing a document that
attempts to resolve the "open issues" that were outstanding in the
"RTP payload format for MIDI" we've been working on in the AVT working
group in the IETF. I believe the I-D that I submitted today:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt
addresses them all (famous last words :-).
So, if you have an interest in sending MIDI over IP networks
using RTP (the IETF telephony and content-streaming protocol), but
you've been waiting for a mature document before committing to reading
through 100 pages of MUSTs and SHOULDs, now is a good time to download
the I-D and send along comments and bugs.
This document, updated to reflect new comments, will form the
basis of the "Last Call" document I submit to the IETF in about a
month or so.
Thanks again,
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
Martin Buechler said
>Alas, don't know what OS it was, but if something remains unclear, I
>might jump in my pants and go ask them.
or you could just let them know about terminatorX and GDam...
Nice to know they have open sourced their code though. I hope that means
they have made enough money out of the product over the past year that
they can afford to make it free and not that they are drawing straws to
make enough money to survive.
Perhaps they could have been more friendly to us rounds here and we
could've promoed them a bit more to our business partners....
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
> is it possible to change my e-mailadress lobotomi(a)suomi24.fi to leppi666(a)suomi24.fi.
> donŽt wanna get out off the list.
You could unsubscribe, and re-subcribe w/the new address.
I think I've done that in this list.
is it possible to change my e-mailadress lobotomi(a)suomi24.fi to leppi666(a)suomi24.fi.
don´t wanna get out off the list.
thanks.
,Tomi
_____________________________________________________________
Kuukausimaksuton nettiyhteys: http://www.suomi24.fi/liittyma/
Yli 12000 logoa ja soittoääntä: http://sms.suomi24.fi/
New Standard Institute has developed "Maintenance Planning and Scheduling", a computer based training. This product is available as an instant download or on a CD and has been nominated "Product of the Year Finalist" by Plant Engineering magazine.
Click on the link below for details.
http://www.newstandardinstitute.com/mps2.cfm?uniqueid=F0876
The material is extracted from New Standard's seminar on the subject, enhanced with animation, interactive examples, pop-up definitions, enlargeable graphics, narration and an internal search function.
We continue to provide our seminars in major North American cities such as Nashville, Toronto, New Orleans, and Orlando.
For personal assistance, contact:
Tessa Marquis
tmarquis(a)newstandardinstitute.com
or by telephone at 203 783 1582
is there anyone here who has any idea how to handle segv's in a
linuxthreads-using application? i know that many of you are aware that
i've used threads a lot in my apps, and grappled with lots of tricky
signal related issues. however, i continue to see something really
deeply ugly in linuxthreads: segfaults seem not to be handled in the
same way as other signals. when a thread in ardour causes a segfault,
that thread is killed (actually, it becomes a zombie, waiting for its
parent to exit) and thats the end of the signal handling. for all
other signals, my code causes them are delivered to a single thread
that is waiting on all waitable signals except SIGCHLD, and we get
control there in a useful way.
its very distressing: a segfault will cause ardour to cease normal
operation, but nothing knows it has happened. if its in (say) the disk
butler thread, the GUI will continue working normally, but nothing
will actually do the right thing.
has anybody come up with code in which segfaults within threads are
handled? i have a few ideas on an approach that might work, but i'm
asking first :)
nb. this is true in JACK as well.
Has anyone made any FFTW 3.0 performance testing? I'm especially
interested to know how it compares on a Pentium 4 (or similar) to the
FFT found in Intel's proprietary performance libraries.
/Anders Torger
