On Tuesday 21 January 2003 00.48, Mark Knecht wrote:
[...GUI...]
Post by Mark KnechtPost by David OlofsonIt's not a top priority for me, since creating sounds from
scratch is workable with a text editor, and loading WAVs is one
trivial line of script per file.
The value of GUI's early is marketing, and I don't think that's
important right now.
That's a good point. Also, most serious users care more about quality
and features, so having something that can do the job is wort a lot
more than having something that looks cool, but doesn't cut it.
Post by Mark KnechtI actually do agree and believe that there's a lot value starting
with good scripts and testing the features BEFORE you invest in a
GUI.
Yeah, you might actually get it *right*! :-) (And rebuilding GUIs
ain't all that fun...)
Post by Mark KnechtLet's go after that first. I'll go look more at what's there
in Audiality. My initial worry was that it was a sequencer, and
wanted to be a master and not an instrument.
It contains a MIDI player, but that's it. It was originally meant for
playing SFX and music in a game - and I just can't stand MODs these
days, and didn't want to rely on SoundFonts, so I decided to use MIDI
+ samples instead. Using the sequencer and the off-line synth is
optional, although you have to use either the C API or scripting (the
latter is definitely preferred most of the time) to load WAVs and
tweak patch parameters, if you have to.
Post by Mark KnechtIf it can respond to
external MIDI, then it looks like it's got many of the other
interesting things today.
Check - and it even maps the new mixer no NRPNs, so you can configure
routing and FXs the way you like directly from the sequencer. There's
nothing I hate as much as having to fiddle with all machines to
switch between songs and projects... Just making sure to play the
init beat of a song is so much smoother. :-)
The only "serious" issue right now is that it's all integer/fixed
point processing; not float32. That means you have 16 bits per synth
voice (if even that) and 24 bit integer mixing. Maybe sufficient for
most work, but you can't make use of 24 bit samples as it is now.
I intend to add full FP support soon, and I might drop the integer
support altogether. It's getting more and more pointless, considering
what will be "low end hardware" in a few years. Audiality can't
compete with a simple MOD player on Pentium and 486 CPUs anyway, and
I'm getting more and more bored with that awful integer code, special
handling of compilers w/o 64 bit int support and whatnot.
On modern CPUs, the choice of algorithms impacts the CPU usage much
more than integer vs float, so for new games, Audiality will still be
a viable option - just don't use convolution based reverbs! ;-) Use
something else for Pentiums, or help maintain the integer support in
Audiality. :-)
Post by Mark KnechtI'm not clear about whether you, David, see this as a linux-sampler project.
It's an independent project which I've been working on for a little
more than a year, as part of a game. I don't know if it makes sense
merging the projects (different priorities, "Choice is Good" and all
that), but it's probably a good idea to share ideas, knowledge and
perhaps some code.
BTW, lots of ideas and even som code for XAP comes from Audiality.
It's entirely possible that I'll split it into a XAP host and some
XAP plugins, given that it's basically structured like that
internally anyway; it's just not as formal as a plugin API, and
doesn't do dynamic loading.
Post by Mark KnechtI did, but it doesn't matter to me. Give me some
instructions and scripts and either way I'll go test it.
Well, 0.1.0 lacks "waveform mapping", so you can't have more than one
waveform per patch. (Right; the demo songs use one channel for each
drum sound... *hehe*) You might want to wait for 0.1.1, but I'm not
sure when I'll release it.
Could make a development snapshot, though, as it's back in a
functional state now. Most interesting news would be some docs, some
envelope generator bug fixes, a much more powerful mixer (with a nice
NRPN interface) and perhaps most interestingly to testers; a demo app
that loads all sounds I've created so far, and sets the engine up as
a MIDI synth. All you have to do is hack the main loader script to
load your WAVs instead.
Post by Mark KnechtHowever, I
think there is value in having a linux-sampler project at this
scale. Something that could be put together rather quickly, tested
pretty easily, to get more people interested in the whole program
overall. With small samples it would run out of memory, but with
larger samples it would have to stream from disk. Getting to the
point where we could do that would be cool. I also think it would
help ring out bugs in the engine.
As GUI's go I think that Battery's is pretty straight forward. They
have something like 50 boxes on the screen. Each box corresponds to
a specific MIDI note and channel. You just load a sound in each box
and go. Each box in Battery has an ADSR, some plugin capabilities
and other things, but to start we just make a matrix of 5x10 or so,
load some wave files and go. That would be a useful device unto
itself. The rest could come later when we've seen the underlying
sample playback engine working.
Sounds like about a day's work to get the required features into
Audiality - but the GUI is more work. Maybe not too far from what I'm
going to implement anyway, though...
The GUI editor I have in mind will basically be a hybrid between a
text editor and a modular synth editor. When it sees constructs it
understands, it displays them as graphical editors instead of text,
so you can edit envelopes, maps and other stuff in a smoother manner.
"Maps" is what rang a bell. What you're describing is basically a
mapping editor of sorts. A map is an object that selects things from
an array, based on some criteria. For example, you could hack a patch
script that to other patches, based on pitch. Each of those patches
could then map to different waveforms, based on velocity.
In the most primitive form, you can just hack something that outputs
a script that sets up the mappings and EGs and loads the waveforms.
For something more sophisticated, make that an application with
access to Audiality's C API, so you can pass the generated script
directly, for instant response.
Planned, and shouldn't be too hard.
Post by Mark Knecht2) It really should handle stereo wave files for samples from day 1
Audiality did stereo samples before it got the name. :-) It's really
just because the original sound FX samples for that game were in
stereo, but it's a nice feature.
That said, I'll probably switch to mono internally (two voices for
stereo), since mono + stereo is yet another 2x cases for the voice
resamplers. (There are currently 40 of them, to support 8/16 x
mono/stereo and 5 quality modes... Lots of macro magic there! *heh*)
This is another relic from the days as a low end games SFX engine.
Post by Mark Knecht3) Should either have a hard audio panner built into each box, or
better yet, respond to MIDI panning,
Check.
Check.
Post by Mark Knechtand velocity events.
Check.
Post by Mark KnechtDon't bother with multiple samples per box (velocity chooses them)
until we've seen it run.
Well, I'll probably get that for free. I'm thinking about creating a
generic "mapper" object. Just give it a number and it hands you a
number back. Then use that to select patches or waveforms based on
whatever parameter you like; MIDI CCs, velocity, pitch or whatever.
Post by Mark KnechtI completely believe this could be script driven in the beginning,
and possibly stays that way under the hood even longer term.
Yeah, that's kind of handy. Though I wouldn't recommend inventing a
custom language and implementing an interpreter for it, unless you
*really* need to. I did it because I'm interested in that kind of
stuff, and because I wanted a streamlined syntax that I like, and the
ability to run scripts reliably in RT context. Still work to do on
the latter, though; need to switch to bytecode first of all.
Anyway, a big advantage with using scripts for the interface is that
you can change the way things work without hacking and recompiling
the GUI or the engine. That's really the main reason why I
implemented it in Audiality in the first place; I could edit and test
sounds and music in-game without even restarting the game.
It's also cool stuff for "power users", who like to play around with
things not meant for ordinary users. :-)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---