>===== Original Message From Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> =====
>What type of hosting service does linuxaudio.org have now in terms of
>space, bandwidth, accesibility of physical site admins and access for
>remote site maintainers?
Currently, the server hosting Linuxaudio.org has been arranged by Daniel
James, so my guess is that it is hosted somewhere in UK, other info is unknown
to me (ironically the site is currently inaccessible for whatever reason).
Daniel?
That being said, in my department (Virginia Tech) I've got an ok to offer
hosting for LA purposes which would mean direct physical access to the
mainframe, virtually unlimited data storage (I am not sure how much we have
right now but we should have probably close to 1TB and there is plenty of
empty slots left on the mainframe for more disks to be added), and most
importantly unlimited bandwidth (although the actual outgoing line is limited
to 100MBit from the node where the mainframe is, but the actual monthly
bandwidth is unlimited). Finally, all data is backed-up weekly with one backup
always being off-site in the case server melts down, dissapears, decides to
grow legs and walk away, or whatever.
Hope this helps!
Best wishes,
Ico
Hi,
I've had the pleasure and misfortune to test both of the widely known
portable MIDI libraries, and now believe I have found one that works to
my satisfaction.
This is not a quantifiable review with benchmarking but the subjective
experience of someone who has implemented a very simple yet nonetheless
professionally implemented, low-latency, jitter-free and real time
application.
(note: to my knowledge, sched_fifo functionality has not been
implemented with either library and is next on the priority list to
implement in the application).
The two candidates are
portmidi (http://www.cs.cmu.edu/~music/portmusic/)
and
RtMidi (http://www.music.mcgill.ca/~gary/rtmidi/)
RtMidi is part of the Synthesis Toolkit (STK) but can be obtained
stand-alone.
For comparison, I have chosen the following criteria:
* Availability
* Learning curve
* Stability
* Features
* Real-Time performance
First thing I did was download PortMidi, mainly because I didn't know
what static linking was at the time and RtMidi (I had found both easily
through Google) I decided I would go for the library with the smaller
size. (As I later discovered RtMidi is available as a seperate library,
but was not packaged for my OS, Debian Etch)
Even while on the site I got a bit suspicious about PortMidi, as there
were quite many 'projects that use portmidi' listed on their site, and a
lot of titles and fancy names, but very little actual software. I've got
a little bit of entrepreneurial experience under my belt, just enough to
tell it is a bad idea to proudly display 'Future Projects' as references.
Nonetheless, I decided to give portmidi a chance, in the hope things
would get better. They didn't. The 'Documentation' was sparse,
cryptically written, and still in the header file (IE no HTML had been
generated). I found this to be quite a careless attitude but I had
decided to try it out and I did.
The API isn't much better. To open an interface, a six parameter
function was necessary, of which two were actually relevant (device ID
and stream pointer). In order to send a message it was necessary to
create a 'buffer' object, write timestamp and message data to it, and
pass it on to a 'write' function. Also, it was riddled with
pointers-to-pointers and various combinations of references and
de-references and I had to revert to plain trial and error to get it to
work. It finally did, though.
After a similar odyssee with the input library, which, unlike my
experience with portmidi I attribute to the fact I had never programmed
C++ before, the application finally stood. Pressing buttons on the
keyboard generated MIDI events. How grand!
However, there was a downside; somehow, pressing and holding keys
generated randomly-spaced additional sounds. "How funny," I thought, "my
physical keyboard must be not appropriate for such fine use."
After battling with C++ polymorphism for DAYS ON END to get the plugin
architecture to work I decided it was time to implement threading.
Looking for a good thread class I realized that is not such a trivial
thing currently. Realizing that RtMidi already had one, and that it was
implemented in an audio environment, I decided to switch MIDI libraries
too as the Thread class was probably optimized for RtMidi.
What a world of difference! I was greeted with a very friendly page
titled 'RtMidi', the author had a picture of himself on the page (it's
VERY reassuring to know he is not hiding from the police) and looked
like he's been meditating a lot, and had it not been for the advanced
C++ functionality used in the class that I hadn't learned yet
('advanced' is relative, I mean the vector class and the concept of
'templates') I would have been done implementing in an hour or two.
Seriously, RtMidi is one of the most beautifully crafted interfaces I
have seen to date, with examples in the beautifully done tutorial.
Unlike portmidi it was possible to create ALSA MIDI virtual devices, and
the code for sending MIDI events was ONE LINE. Using references it was
possible to write a callback function for application plugins that
DIRECTLY affect the raw data sent. Clearly, I had a winner. When I
tested it I realized what had seemed like a broken keyboard was simply
how portmidi responded to repeated, fast events; I had not turned off
KeyRepeat events in the event handler, and what was left of them with
PortMidi were randomly spaced events between 200 and 500ms apart,
somehow mangled in the obscurity of the code I can only presume. With
RtMidi it was possible to recognize the events for what they were,
crystal clear, fast and evenly spaced KeyRepeats clogging my synthesizer
with utmost precision. I have yet to fix the KeyRepeat problem, but it
tought me a lot about performance. Perhaps the 'KeyRepeat' test could
evolve to a rather good rule-of-thumb benchmark for MIDI performance.
And I haven't even implemented SCHED_FIFO yet.
As a conclusion, I can draw the following ratings matrix for the two, I
can assume the care with which documentation is crafted is a good
indicator for code quality, and I can only recommend: Keep your hands of
portmidi. Write a wrapper if you need to use C, but for heaven's sake if
you don't want all your musical timing ruined, just don't use portmidi,
period.
MATRIX
1: Useless 5: Excellent
portmidi RtMidi
Availability 4 4
Learning curve 1 4
Stability 3 4
Features 3 4
Real-Time performance 1 5
Carlo
-X-X-X-
Did you think this review was helpful for you? Please give a simple 1 to
5 rating, or a quick comment. Thank you.
Hello all.
I've always steered clear of writing GUIs, so my experience is pretty
limited. But now I find myself needing a toolkit/widget set.
What's recommended? I'd prefer not to have to move my app from C to
C++ just to implement the interface, so that's quite a few out of the
window.
I don't really want huge dependencies for a knob, text box and a
button, either.
And something that's installed as default in most distros would be
good, too.
So, what I want is everything. And it should be simple, too.
Any suggestions?
James
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
>Hi,
>
>I've had the pleasure and misfortune to test both of the widely known
>portable MIDI libraries, and now believe I have found one that works to
>my satisfaction.
>
>This is not a quantifiable review with benchmarking but the subjective
>experience of someone who has implemented a very simple yet nonetheless
>professionally implemented, low-latency, jitter-free and real time
>application.
>
>The two candidates are
>
>portmidi (http://www.cs.cmu.edu/~music/portmusic/)
>
>and
>
>RtMidi (http://www.music.mcgill.ca/~gary/rtmidi/)
Well, I guess the midishare guys should promote more...
http://midishare.sourceforge.net/
Lee Revell:
>
> On Tue, 2006-02-21 at 14:08 +0100, David Kastrup wrote:
>> Who is talking about not paying?
>
> This whole discussion was ignited when someone advocated pirating (or
> stealing, or whatever) commercial software.
>
Why don't you want to distinct between copyright violation (which is
a gray area, different from country to country) and stealing?
Please pardon cross postings and feel free to distribute this announcement.
ICMC 2006: Extended Deadlines
Y'all are invited to submit your best, finest, or even craziest works to
the 2006 ICMC conference to be held in New Orleans, Louisiana, USA from
November 6 - 11, 2006. To facilitate the submission of your works we
have extended the deadlines:
Music/Video/Installations: March 18 (Sat), 2006
Papers: March 11 (Sat), 2006
This conference is not only a historic collaboration between ICMA and
SEAMUS (Society of Electro Acoustic Music in the US) but is also a
conference that will help with the recovery of a city, its people, and
its culture.
We have also further updated performance resources which includes the
Ensemble Surplus from Germany, NextEns from Cincinnati, Cat 5 from
Mississipi, the infamous Convolution Brothers, dancers from the Tulane
Theater and Dance Department, our own Tulane Music Department Musicians,
Korean traditional instrumentalists from Seoul, and much more.
During the conference we'll be giving away gifts and prizes (as well as
lots of beads!) made possible by generous donations by our corporate
sponsors such as Bias(numerous copies of Peak Pro XT), Parallax (10 BS2
boards with on board bread-boards), Mixmeister (more than $1000 worth of
products), Maxim-IC (no not the magazine!), Electrotrap ($800 worth of
sensors for your HCI needs), empreintes DIGITALes (special "ICMC" CD for
all registered participants), Soundhack (5 copies of spectral shapers),
fxpansion (one of each software type) and many more goodies.
Please visit www.icmc2006.org regarding updates and details. Laissez les
bon temps roulez!
Sincerely,
Tae Hong Park, ICMC 2006 Conference Chair
Please pardon cross postings and feel free to distribute this announcement.
ICMC 2006: Extended Deadlines
Y'all are invited to submit your best, finest, or even craziest works to
the 2006 International Computer Music Conference to be held in New
Orleans, Louisiana, USA from November 6 - 11, 2006. To facilitate the
submission of your works we have extended the deadlines:
Music/Video/Installations: March 18 (Sat), 2006
Papers: March 11 (Sat), 2006
This conference is not only a historic collaboration between ICMA and
SEAMUS (Society of Electro Acoustic Music in the US) but is also a
conference that will help with the recovery of a city, its people, and
its culture.
We have also further updated performance resources which includes the
Ensemble Surplus from Germany, NextEns from Cincinnati, Cat 5 from
Mississipi, the infamous Convolution Brothers, dancers from the Tulane
Theater and Dance Department, our own Tulane Music Department Musicians,
Korean traditional instrumentalists from Seoul, and much more.
During the conference we'll be giving away gifts and prizes (as well as
lots of beads!) made possible by generous donations by our corporate
sponsors such as Bias(numerous copies of Peak Pro XT), Parallax (10 BS2
boards with on board bread-boards), Mixmeister (more than $1000 worth of
products), Maxim-IC (no not the magazine!), Electrotrap ($800 worth of
sensors for your HCI needs), empreintes DIGITALes (special "ICMC" CD for
all registered participants), Soundhack (5 copies of spectral shapers),
fxpansion (one of each software type) and many more.
Please visit www.icmc2006.org for details on updates and conference
information. Laissez les bon temps roulez!
Sincerely,
Tae Hong Park, ICMC 2006 Conference Chair
Announcing Shelljam 0.0.3.
Almost everything is broken in this release. I am providing it to
demonstrate how absolutely, admirably, extensively, beautifully and
fantastically plain wonderful the new MIDI interface, RtMidi is. It is
so fast you won't believe it. And it does NOT even use low latency
scheduling yet.
Also, as a sneak peak, the rudiments of a plugin architecture are
present. Instruments may be created deriving off a base class that has a
virtual callback function (see shelljaminstrument.h in the source for
API... it is NOT frozen)
There are also two cutish pictures of myself on the web site now.
Thanks for your interest.
Carlo
>===== Original Message From Eric Dantan Rzewnicki <rzewnickie(a)rfa.org> =====
>On Fri, Feb 24, 2006 at 09:43:01AM +0000, Daniel James wrote:
>> Hi Ico, hi Eric,
>> >That being said, in my department (Virginia Tech) I've got an ok to offer
>> >hosting for LA purposes which would mean direct physical access to the
>> >mainframe, virtually unlimited data storage (I am not sure how much we
>> >have right now but we should have probably close to 1TB and there is
>> >plenty of empty slots left on the mainframe for more disks to be added),
>> >and most importantly unlimited bandwidth
>>
>> That would be a great improvement, and would allow us to host or stream
>> a lot of music files or offer software downloads. I can easily set up
>> linuxaudio.org DNS to point to that.
>
>I notice Joern's mail concerning moving linuxdj content to
>linuxaudiodev.org and that somehow involving Paul ... I've been a little
>out of the loop lately. Can someone sketch in the current state of the
>various sites Ico is proposing to consolidate?
In a nutshell, the lad site is being moved to Paul's server but the domain
continues (at least for the time being) to be inaccessible. Another
consideration is the .com extension current linuxdj has which may be something
worth discussing, especially considering that most of the LA software is not
of corporate origin. As far as my proposition is concerned, you are the first
one expressing any interest in it...
Regarding moving Linuxaudio.org, I'd be more than happy to provide space for
such a move as well as any other Web-related Linuxaudio.org incentives,
including potential consolidation of project summaries into one Wiki
meta-resource, as suggested in my earlier e-mail.
Best wishes,
Ico