Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: David Olofson (audiality_AT_swipnet.se)
Date: ke tammi 26 2000 - 19:32:03 EST
On Mon, 24 Jan 2000, jfm3 wrote:
> Benno Senoner wrote:
[...]
> > Therefore if you want "hard-realtime" and are paranoid as David Olofson says ,
> > go with C/C++ , else you have to trust 100% your interpreter, and very often
> > interpreters aren't designed with realtime in mind.
>
> I agree. The problem is when I want "real time" sequencing with "logic" (not
> Logic(TM)). If I want to give a command to my sequencer like "in this given
> MIDI pattern, reduce all CC#11's greater than 72 to 72." my only hope is with a
> little extension/command language. It's a hard problem and any solution is
> impressive.
Hmm... Sounds like you need a small, fast and very flexible sequencer
core, with a nice interface that allows you to "directly" access
events using a nice scripting language. That way, real time problems
and "reacting to changes ASAP" gets completely out of your code, and
itho the sequencer - which in turn has only two things to keep in
mind:
1) Play back from the database with high accuracy
2) Implement changes from the edit API ASAP
Sounds pretty simple, right? :-) (Wait 'til it's time to design the
interfaces...) *hehe*
This, however, does not enable you to do true real time
nondestructive MIDI processing with your scripts - the scripts are
more like non-RT software controlling a piece of custom hardware.
You could get around that to some extent by throwing in support for
some machine code like bytecode in the sequencer engine, but that
looks more like something you'd do if you really *have* to execute
the code in hard real time, and still need the flexibility w/o
hacking the engine source code. Perhaps there really is a need for an
interpreted or "semicompiled" language that's deterministic rather
than "nice" and fast?
I was designing such a beast for a games development tool, the
Arcade Game Constructor (AGC)...
http://www.angelfire.com/ar/agc
(Sorry, no code but some simple DirectX video hacks, and a command
line interpreter. I'll pick it up again some day, I think. Maybe if I
can have another lifetime or so... ;-)
> Keykit does an admirable job of getting language interpretation done quick enough
> to do real music. It isn't an ideal language, but it certainly is useful, and if
> nothing else is proof of concept. I don't think it qualifies as "hard" real
> time, but yet it is still a practical tool.
>
> In my mental wanderings on the subject, I came across a good site that addresses
> a lot of developers concerns regarding garbage collection, including real time
> stuff. Did you know that in practically every implementation malloc() or
> ::operator new() is not guaranteed to finish in bounded time?
Of course; it's virtually impossible to do that in a system that's
not 100% hard real time. (ie the kernel is fully RT, no swapfiles
etc...) What if you're out of RAM, and the kernel has to do some
swapping to get you some? You need to preallocate a sufficient heap
and lock it to even have a chance to implement real time dynamic
allocation.
Most hard RT applications don't use normal forms of dynamic
allocation, but rather pools/lists/stacks of free objects, or simply
permanently allocated memory.
//David
.- M u C o S -------------------. .- A u d i a l i t y ----------------.
| A Free/Open Multimedia | | Rock Solid, Hard Real Time, |
| Plugin & Integration Standard | | Low Latency Signal Processing |
`------> www.linuxdj.com/mucos -' `--> www.angelfire.com/or/audiality -'
.- D a v i d O l o f s o n ------------------------------------------.
| Audio Hacker, Linux Advocate, Open Source Advocate, Singer/Composer |
`----------------------------------------------> audiality_AT_swipnet.se -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST