om-synth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Om-synth] issues with om


From: Dave Robillard
Subject: Re: [Om-synth] issues with om
Date: Wed, 14 Dec 2005 16:51:13 -0500

On Wed, 2005-14-12 at 14:57 +0100, Atte André Jensen wrote:
> 1) When I load alot (one tune has 7 sounds for instance) of medium 
> complex sounds un-nice things start to happen: Audio breaks up 
> (sometimes, not all the time), even though top only shows om using < 70% 
> cpu.

This is the fault of whatever plugins you're using.  I don't currently
check the realtime safe flags of the plugins (I should, yeah).  I may
just have them not show up at all, which is the easy fix.  You might be
running non realtime safe plugins that have CPU usage all over the
place.

Om itself is and always has been very strictly hard realtime safe, I can
tell you that.

> 2) Sounds randomly load with an error like (this happens with with 
> loading from lash and from om_gtk, and it also happens under very light 
> load):
> ERROR: Unable to make connection 
> /lo_bass_intro_01.om/product_iaic_oa_3/Product Output -> 
> /lo_bass_intro_01.om/product_iaic_oa_5/First Input
> ERROR: Unable to make connection 
> /lo_bass_intro_01.om/product_iaic_oa_5/Product Output -> 
> /lo_bass_intro_01.om/product_iaia_oa_3/First Input
> ERROR: Unable to find port /lo_bass_intro_01.om/product_iaic_oa_5/Second 
> Input
> 
> 3) Most of the time patches loads with modules thrown a few modules 
> thrown randomly over the canvas. Mostly product modules and audio output 
> modules. This is not a huge problem, but it's very anoying.

These two are communication issues.  The bane of my goddamn existance,
frankly.  I get it occasionally too, I'll have to slow things down a
bit.

It's a fun game of randomly increasing delays littered throughout the
code until things usually work.  This is the one thing that makes me
regret the seperate client/server model.

> 4) Om (as mentioned in a previous post) doesn't seem to handle very 
> standard stuff like sustain (or hold) pedal.

That would be because I didn't have a keyboard with me until now. ;)
Hold pedal support will come soon, now that I do.

> So, what are my options? I can think of a few:

> 4) Investegate into my kernel. There might be some performance gain 
> here, but again this will come back with heavier load.

Are you running a realtime patched kernel? (latency, not permissions)

> 5) Switch back to csound (or look in other directions, supercollider 
> comes to mind). Although I program much slower in csound and I'm not too 
> fond of it's ancient language, it's rock steady, very fast, has dynamic 
> voice allocation and plays back samples.

A (better) DSSI sampler plugin would allow you to play samples in Om.
You can right now with the sampler that comes with the DSSI
distribution, but it's a pretty trivial thing.

Dynamic voice allocation will come in the form of a special node with an
"activate voice" input (ie if it's high, the voice will run, or maybe
vice versa).  This is a very old idea as well (it came up on the LAU
thread about the "ultimate modular synth" before I even wrote a single
line of code).  Noone's really needed it yet, so I havn't bothered.

> So here's my point:
> 
> I realize that om is free software and I get what I paid for (actually 
> quite a lot more). And I'm in no way critizising the programming effords 
> put into om. But the project would be alot more usable in a real-world 
> situation if:
> 
> 1) Attention was paid to efficiency. This both means optimizing om 
> itself, but also implementing things like dynamic voice allocation.

Ahem.  Om is one of the most rigorously realtime safe and performance
audited (in the audio thread anyway) linux audio apps I know of.  The
version in CVS is DRAMATICALLY more efficient at mixing down ports and
whatnot than 0.2.0, but Om's overhead compared to the plugins is so
insignificant it matters little.

> 2) Stability was a main consideration in the development model. This 
> might mean putting new features on hold, and doing what we all hate: 
> testing and fixing bugs. This might also include making official 
> releases more often. This also means that that cvs should always be usable.

No, CVS should not always be usable.  That is what CVS is for.  You're
not a programmer and have no idea what you're talking about, so I'll
forgive you on this one.  I /should/ make more frequent releases, which
I'll try to do, but that's a seperate issue.

On stability, every release I've made has been very, very thoroughly
hammered on with the demolition client (which tests much more rigorously
than any human could).  0.2.0 has run for 24 hours being stress tested
by it without a single hitch in valgrind (which finds anything, even if
it's not a fatal bug).  If you can crash the 0.2.0 engine, you're more
clever than I (and I want to know how).  

CVS is CVS.  It's where developers do their work.  Don't go slamming a
project because CVS is unstable, that's beyond stupid.  Changes that
break things need to happen for progress to occur, that's a law of
programming if there are any.

BTW, you have just implicitly volunteered to thoroughly test the next
release. :)

Anyway, I don't know what the point of this diatribe is.  Things get
done when people need them.  Noone needed hold pedal, hence no hold
pedal support.  Need hold pedal support?  Mention it (like you did
before).  It'll take me less than an hour to do that, it's not a big
deal at all.  Don't post rants to the list about how Om sucks in general
(no matter how nicely worded) - mention issues, and we'll tackle them
individually, as always.

I'm not psychic, I don't spend my (spare) time rubbing a crystal ball to
determine what people need.  When people need something, they tell me,
and I do it, most often right when they tell me.  Most anyone on this
list or on IRC can tell you that.

As for the time being, I just moved to the other side of the planet,
need to find a home to live in within 2 weeks, and move another 6 hours
away from where I'm staying right now and start classes the day after
new year's (ie hung over).  Yet, I still fixed Alsa MIDI today so it's
usable again, and learned about how MIDI hold pedal messages work so I
can implement it, all while taking a short break from searching for a
home, buying xmas presents, and packing, which I've been doing all day.

What did YOU do today? 

-DR-

P.S. Development will pick back up in January.  Om isn't dying.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]