Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Tuesday 21 January 2003 00.48, Mark Knecht wrote:
[...GUI...]
> > It'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=20
and features, so having something that can do the job is wort a lot=20
more than having something that looks cool, but doesn't cut it.


> I 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=20
ain't all that fun...)


> Let'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=20
playing SFX and music in a game - and I just can't stand MODs these=20
days, and didn't want to rely on SoundFonts, so I decided to use MIDI=20
+ samples instead. Using the sequencer and the off-line synth is=20
optional, although you have to use either the C API or scripting (the=20
latter is definitely preferred most of the time) to load WAVs and=20
tweak patch parameters, if you have to.


> If 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=20
routing and FXs the way you like directly from the sequencer. There's=20
nothing I hate as much as having to fiddle with all machines to=20
switch between songs and projects... Just making sure to play the=20
init beat of a song is so much smoother. :-)

The only "serious" issue right now is that it's all integer/fixed=20
point processing; not float32. That means you have 16 bits per synth=20
voice (if even that) and 24 bit integer mixing. Maybe sufficient for=20
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=20
support altogether. It's getting more and more pointless, considering=20
what will be "low end hardware" in a few years. Audiality can't=20
compete with a simple MOD player on Pentium and 486 CPUs anyway, and=20
I'm getting more and more bored with that awful integer code, special=20
handling of compilers w/o 64 bit int support and whatnot.

On modern CPUs, the choice of algorithms impacts the CPU usage much=20
more than integer vs float, so for new games, Audiality will still be=20
a viable option - just don't use convolution based reverbs! ;-) Use=20
something else for Pentiums, or help maintain the integer support in=20
Audiality. :-)


> I'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=20
more than a year, as part of a game. I don't know if it makes sense=20
merging the projects (different priorities, "Choice is Good" and all=20
that), but it's probably a good idea to share ideas, knowledge and=20
perhaps some code.

BTW, lots of ideas and even som code for XAP comes from Audiality.=20
It's entirely possible that I'll split it into a XAP host and some=20
XAP plugins, given that it's basically structured like that=20
internally anyway; it's just not as formal as a plugin API, and=20
doesn't do dynamic loading.


> I 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=20
waveform per patch. (Right; the demo songs use one channel for each=20
drum sound... *hehe*) You might want to wait for 0.1.1, but I'm not=20
sure when I'll release it.

Could make a development snapshot, though, as it's back in a=20
functional state now. Most interesting news would be some docs, some=20
envelope generator bug fixes, a much more powerful mixer (with a nice=20
NRPN interface) and perhaps most interestingly to testers; a demo app=20
that loads all sounds I've=A0created so far, and sets the engine up as=20
a MIDI synth. All you have to do is hack the main loader script to=20
load your WAVs instead.


> However, 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=20
Audiality - but the GUI is more work. Maybe not too far from what I'm=20
going to implement anyway, though...

The GUI editor I have in mind will basically be a hybrid between a=20
text editor and a modular synth editor. When it sees constructs it=20
understands, it displays them as graphical editors instead of text,=20
so you can edit envelopes, maps and other stuff in a smoother manner.=20

"Maps" is what rang a bell. What you're describing is basically a=20
mapping editor of sorts. A map is an object that selects things from=20
an array, based on some criteria. For example, you could hack a patch=20
script that to other patches, based on pitch. Each of those patches=20
could then map to different waveforms, based on velocity.

In the most primitive form, you can just hack something that outputs=20
a script that sets up the mappings and EGs and loads the waveforms.=20
For something more sophisticated, make that an application with=20
access to Audiality's C API, so you can pass the generated script=20
directly, for instant response.


> To clarify a couple of things:
>
> 1) It's a Jack app

Planned, and shouldn't be too hard.


> 2) It really should handle stereo wave files for samples from day 1

Audiality did stereo samples before it got the name. :-) It's really=20
just because the original sound FX samples for that game were in=20
stereo, but it's a nice feature.

That said, I'll probably switch to mono internally (two voices for=20
stereo), since mono + stereo is yet another 2x cases for the voice=20
resamplers. (There are currently 40 of them, to support 8/16 x=20
mono/stereo and 5 quality modes... Lots of macro magic there! *heh*)=20
This is another relic from the days as a low end games SFX engine.


> 3) Should either have a hard audio panner built into each box, or
> better yet, respond to MIDI panning,

Check.


> volume

Check.


> and velocity events.

Check.


> Don'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=20
generic "mapper" object. Just give it a number and it hands you a=20
number back. Then use that to select patches or waveforms based on=20
whatever parameter you like; MIDI CCs, velocity, pitch or whatever.


> I 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=20
custom language and implementing an interpreter for it, unless you=20
*really* need to. I did it because I'm interested in that kind of=20
stuff, and because I wanted a streamlined syntax that I like, and the=20
ability to run scripts reliably in RT context. Still work to do on=20
the latter, though; need to switch to bytecode first of all.

Anyway, a big advantage with using scripts for the interface is that=20
you can change the way things work without hacking and recompiling=20
the GUI or the engine. That's really the main reason why I=20
implemented it in Audiality in the first place; I could edit and test=20
sounds and music in-game without even restarting the game.

It's also cool stuff for "power users", who like to play around with=20
things not meant for ordinary users. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- 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 ---