12 Jan
2006
12 Jan
'06
11:23 p.m.
On Thursday 12 January 2006 18:06, Jay Vaughan wrote:
Still shouldn't be much code to change - but someone still has to
actually do it.
Well, I decided to do it the hard (integer) way in the real time part
of Audiality, but as maximum portability was a requirement, I had to
do it in pure C - and that's certainly no fun, especially not on
compilers without long long support. (MUL and DIV are so much nicer
in asm, but AFAIK, no high level languages allow you to make proper
use of it. :-/ )
The more interesting part, the modular synth engine (which is to be
usable in the real time context in future releases), uses FP, because
1) I didn't have much time for hacking, and I'd
rather have it running on FP than not at all,
2) it seems like integer processing is slower
than FP on most machines with proper FPUs,
3) at the time, I knew of no integer-only hardware
where real time modular synthesis was viable, and
4) most DSP stuff is easier to code in FP anyway,
at least as long as you can't throw in some asm.
Of course, for maximum scalability (which is a design goal, although
not the primary one at this point), it would be best to have both FP
and integer versions of everything - and maybe I'll do that
eventually. However, the primary target platforms for the stuff I'm
working on now is - guess what - x86 and PPC, so I have to focus on
getting it to work (and preferably run fast) on those, first.
If you just don't have the proper motivation to hack the code, you
won't do it. Goes for everything, whether it's Free/Open Source or
commercial. Unless someone needs the software, thinks hacking it
would be fun, and/or believes there is money waiting to be made, the
code doesn't get written.
Then again, the DSP code usually accounts for just
a fraction of
the code of a full application.
.. unless you put such DSP code in certain 'key infrastructure'
components of the system .. And heavy duty,
DSP centric applications
(ie ones with lots of DSP code) probably won't be of much use
without a GFLOPS class CPU anyway.
I would think you can compile and run them on just about anything -
but without proper FP support (that is, an extremely fast integer
CPU + FP emulation, or "anything" with a proper FPU), they won't
run fast enough to do anything useful, unless all DSP code is
translated to integer/fixed point.
its amazing though, how there are good quality examples of audio/DSP
code which don't require FP .. which do in fact use integer/fixed
point math .. and which function just fine in cheap hardware .. I can certainly
understand why someone who isn't seriously
interested in the odd few platforms with enough oomph but no FP,
would lack the motivation to write and/or maintain code that is
relevant only on these platforms.
oh, so can i, for sure.. i mean, if you've taken the easy path once,
no need to consider any other path twice .. except to bemoan the
existence of such other paths, of course .. regardless, there certainly seems to be potential in
the GP2X' lowly
cpu's for interesting audio hacking, and i certainly hope its
acceptable to the cognescenti to recognize this fact, FP or none ..
Well, I'm considering getting one, though I'm not totally sure what
I'd use it for. (Except plain fun, of course, which is no small part
of the whole Free/Open Source thing.)
Are there any restrictions WRT which Linux drivers are available? (I'm
thinking external USB devices and the like.) Does it support (USB)
keyboards and mice? (A foldable rubber keyboard and some sort of
tracker-like sequencer could be useful. Or is there a foldable rubber
MIDI/USB keyboard out there somewhere?)
Another thought: Is there a market for shareware games? (Ports, at
least - it'd have to be a rather large market for dedicated game
designs to be viable, I think.)
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'