i'm looking for a sampler instrument file format similar to .nki, .sf2
or akai instruments. is there an open standard existing already, perhaps
even accompanied by some sort of library?
-- Leonard Ritter
> On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote:
> Further to that, something constructive: perhaps you could try telling
> your customers why *you* chose linux, rather than trying to find reasons
> to tell them *they* should.
My reasons, from back in about 2000, were "cost" and "interesting".
First off the license costs were not hard to sell. And secondly that I
personally wanted to program in Linux. I thought it would be interesting
--- and it has been fun. Also the company was kind of a crapshoot and I
wanted the professional experience on my resume if I needed to go get
another job. Embedded Linux sounded good to me.
I want to stick with Linux and hoped there were some measurable
performance differences to tout. Sounds like there aren't, really.
And now for some more kind of Dilbert-esque background for the curious...
A couple of years ago, we tried answering this question by measuring the
time between a midi impulse on a rigged midi cable and audio output on
an oscilloscope. We tested Receptor vs Windows 2000 running VStack. The
Receptor was not more responsive but was less jittery in its reponse.
We engineers didn't feel that the results were carefully enough
generated to be publicly announced, but we felt that our hunch was being
Then I made some perhaps loose comments about how Linux is less bloated
than Windows. True, but not quantifiable.
Then there is the general (and vague) perception among many in the music
biz that Windows is not for pro audio.
All of these factors led our non-tech people here to start saying that
our OS was better. Being an engineer, and not being able to quantify
"better", I would cringe when they would say that and qualify endlessly.
But I also couldn't prove anything either way, so I kind of left it.
As time has passed, I have found that I was naive about the costs of
Wine (VST compatibility, Linux (hardware compatibility, especially USB
and firewire audio/midi devices) and the costs of getting programmers
productive on Linux as a development platform.
Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA
drive support and our Wine is getting old (vinegar? %). Our code could
do Windows pretty easily. Should I push for that, or move to a newer Linux?
There you have it. Life in the software business.
By the way, I appreciate all of the comments. I expected it might be a
loaded question! ... mo
> "Frank Smith" <frsmith(a)gmail.com>
> Nice point and this is the strength of OS. the problems are addressed
> far quicker than in Prop' software.
Yes, that's good. Microsoft doesn't give a hoot about professional
audio. We can actually tweak the OS, and Wine, to improve performance of
our specific application.
We got an improvement of Wine's CRITICAL_SECTION implementation in
(using futexes) that helped DFH perform during heavy use of a particular
Can anyone suggest ways to compare audio/midi performance between Linux
and Windows that (1) are relevant to non-technical musicians and (2)
make Linux compare favorably?
Not things like "I just don't like Windows" or software feature
comparisons or the politics of open vs. closed source, but rather things
like responsiveness to audio interrupts, RAM footprint of the OS and ...?
I work for a company that sells a Linux based piece of hardware that
plays windows VSTs. We spend alot of time on compatibility, especially
on getting the plugins to work with Wine. I often get asked about
switching to Windows and I don't have a good answer.
My sense is that the main benefit of Linux is that audio interrupts are
serviced faster and more predictably than in Windows because of
SCHED_FIFO and Linux's low overhead. And clearly musicians could feel
that, especially at lower buffer size settings so that's the kind of
thing that could matter.
But is it _really_ true? Is there a standard way to measure it? Or
published results about it?
Are there any other things to compare? Thanks for any input. I _want_ to
believe! %) ... mo
PS: apologies for any confusion that comes from posting to both
linux-dev and linux-user. I wasn't sure which list this is more
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability separate
the algorithmic to the displayed value of a parameter.
I'm finding this inability is leading to non-ideal programming habits.
Let me show what I mean with a few examples.
I have a control that represents a gain knob (say -12dB -> 12dB):
What's best for the run function is a value that represents the ratio
which I can simply multiply the audio by as it it keeps the maths simple
(0.25 -> 4). What's best for display is decibels (as that is way gain is
I can't do this with LADSPA - so as I programmer I'm left with a lose-lose
* I either choose a parameter range of -12 -> 12 (dB) and convert that to
a ratio every time the run function is called:
fGain = pow(10, *(psMyPlugin->m_pfControlGain) /20);
Which is an unnecessary use of cpu. (and as someone who has mixed many
albums on computers you need every scap of cpu you can get)
* Or I choose to use 0.25 -> 4 as my range. Now users are faced with a
parameter they don't intuitively understand (it is contrary to every other
bit of audio gear they have ever used) - most people cannot do
20*Log10(Gain) in their heads to work out the equivalent value in dB.
Of the two choices I choose the first, better to eat up too much cpu than
to have an interface that is unintuitive, but this is not ideal.
This gets worse when you have a control for something like 'warmth'. The
user does not need to know the range of values required to apply warmth in
an efficient manner (it won't mean anything to them), they just need to
know how much (0%-100%).
Another example - presets
I have a control that allows an operator to chose one of fifty presets
(say a reverb with small room, medium room, large room, hall etc). I don't
have a choice this time. Internally using an integer to represent the
different presets is fine, it's exactly all I need.
However even though I know what the preset is, I cannot display it's name
back to the user, so our user is left with a set of meaningless numbers
which they must resolve into names by some other means (print the doco out
and stick it on the wall?)
What I'd find useful in the api is an optional 'get_display' function
which allows the host app to get a human interpretation of a parameter for
display. It would only need to be called when a plugin windows is opened
or when a parameter is changed. Since the host has to convert the
parameter to a string in order to display it anyway, this is not a extra
step overall. We are just bringing it into the realm of the plugin.
/* pseudo code */
void GetMyDisplay(char *stDisplay, int Size, unsigned long Port)
stTemp[Size-1]='\0'; /* truncate it to what the host wants*/
stTemp[Size-1]='\0'; /* truncate it to what the host wants*/
Now for a wish.
GUI - under OSX or windows this isn't such a big drama, there's only one
GUI environment to deal with. under Linux it's a different matter.
I sometimes think the best thing to do is to provide enough hints to the
host so it can render a more comprehensive gui, if it desires, rather than
the plugin drawing the gui as is traditionally done. This would entail a
1) Utilize ports of type: LADSPA_PORT_OUTPUT | LADSPA_PORT_CONTROL
what is that?
-> it's a meter, a light, etc
We'd just need some hints defined and the rest is up to the host
(most host apps already have their own audio specific widgets. we just
need to tell them which ones we want to use). These all need to be bounded
as any other control would be.
/* a peak meter, expects a ratio not a dB value */
/* a vu meter, expects a ratio not a dB value */
/* Some meters like gain reduction meters in a compressor meter backwards,
ie illuminated from max value downwards rather than minimum value upwards
/* a simple on/off light */
/* a light which has intesity */
2) Add control layout to the port definitions
Could be done as by defining arbitrary bounding boxes.
* | gain | |
* +----------+ meter|
* | warmth | |
- control colours in the layout hints
- background & logo images in the descriptor
This would all be optional for the host
Thanks for taking the time to read though all this, turned out to be
longer than I anticipated!
I am trying to record audio from my STM webcam the driver for it's sound card's driver is loaded automatically as snd-usb-audio.
But When I try to record through sound recorder, it did't record anything.
On seeing at the catc traces I came to know that the sound recorder even don't set the streaming alternates.
Bharat Singh Gusain
Plot no-1, Knowledge Park III
Greater Noida - 201308, India
Mobile - 9911121667
maybe it's just another of my dumb questions, however I would like to
know whether it is happened to you that a sound processing plugin
(LADSPA, LV2, VST, etc.) crashed (segm. faults, etc.).
In such case, can you estimate how often does it happen that such
plugins are misprogrammed?
Thanks in advance,
On 1/25/07, Carlo Capocasa <capocasa(a)gmx.net> wrote:
> > We need more moderators on the list, mail me ;-)
> Hey ho, thought police! Let us all think right and be right and have
> someone else decide on what that 'right' actually means!
> What I'm getting at is, you have absolutely no way of knowing whether or
> not Israel actually is an Apartheid state, or how that might or might
> not be relevant to this list.
> What's with the people who might want to write a song about Israel
> and/or Apartheid? Oh right, that's not important, we have more important
> things to do, we are all about National Security, and stray thinkers are
> a danger, so we must silence them with whatever means necessary to us.
> So in come the moderators and you have to watch your step around here
> before you say anything about Jews or you get busted.
> Now personally I couldn't give a bit more about what Jews aren't or are
> doing, but it seems every time you mention them everybody goes nuts.
> What goes? What's REALLY behind this?
I think I own everyone an apology for being part of all the fuss that
has been going on the list for a few days now.
When I wrote the above quoted sentence I did not imagine the
(disproportionate) consequences this would have, and more importantly
never intended to imply that a moderator was here to control if what
was said on the list was right or wrong thinking. Although I do think
that as a moderator and administrator myself I need to make sure a
certain ethic is respected, the best way to deal with the original
problematic message was just to ignore it, since the replies only
caused a flame war.
Concerning the need to decrease the work load of moderating the list,
I propose another approach :
As discussed previously on the list, we will certainly move to
linuxaudio.org. Let's use this opportunity to tune mailman to our
needs. There are not so much actual message that fall into the
'in-need-of-moderation' category. There are two actually : non-member
messages and HTML messages. The biggest part of the job is to filter
spam. My idea is to find a way to tweak (or apply an existing patch
to) mailman so that messages marked as spam get discarded
automatically, and also to be able to feed spamassassin with new spam
samples directly from the moderation page.
If you are willing to help, if you know of an existing solution or if
you happen to have ideas concerning this, please, drop me an email. It
is as of this momment the best way to help, and is the first step
towards making moderation faster for every one.
Again accept all my appologies.
Just wondering if this will get through from my Gmail act.
I have loaded 64studio onto my only new SATA drive and now cannot boot at
all ( black screen cursor only)
Anyone any idea how I goot the machine?
Or do I need to reinstall it all again. ( It did ask to install grub to the
MBR and I said yes)