[linux-audio-user] RE: Linux sampler projects
ninjadroid at ml1.net
Mon Feb 23 16:13:27 EST 2004
At Mon, 23 Feb 2004 12:01:33 -0800,
Matthew Allen wrote:
> Pete, please keep on doing whatever the hell it is you want to
> do. It was great getting in this morning and having a freshmeat
> announcement with an update of specimen. This mail is not a feature wish
> list for specimen (or for anyones sampler) this is just what I like
> sampler wise.
Well, I'm certainly not going to stop coding, and I'm quite interested
in what features other people find useful because I'll probably find
them useful as well (and then implement them).
> Things Kontakt did that made me want to switch.
> 1. Easy of importing a bunch of samples at a time (or if you have a
> GUI use it right).
Definitely. The first thing I wrote when I started working on Specimen
was the GUI, and I still think from the GUI in when I add features. The
current interface works well enough, but unless you write a script to
generate .beef files (not hard to do sense they're simple xml files),
it isn't sufficient for quick creation of huge banks. I'm planning
on adding a pane on the left with a scrollable keyboard layout for
quick note and range assignment, and a pane on the right for sample
browsing which can be customized to hold entries for your favorite
directories. Probably gonna make both panes collapsable as well,
for those who like the minimalist setup, but that's all taking
a back seat at the moment...
> 2. Modulation sources and Destinations coming out my ears.
...because my focus is on the ability to create music *first*, and
the ability to accomplish specific tasks (like creating a huge bank)
> Modulator can be tempo (midi time clock) synched.
I didn't think about that, good call.
> Pretty much every parameter can be modulated (even ones most people
> wouldn't want to modulate). You can even modulate the parameters of
> the modulators with more modulations, its very GNU.
Ok, which approach is best:
1) A finite number of modulators which can control various parameters
and/or each other.
2) A modulator per parameter (yikes).
3) A dynamic modulator management system, so you can have an arbitary
number of modulators which can modulate any parameter that supports
modulation (which should be all).
I think number 3 would be the way to go, so long as it's done in an intuitive
fashion. In the meantime, I plan to implement number 1.
> Envelope follower
> 32-stage step modulator
> Poly aftertouch
> Mono aftertouch
What do these things do? Sorry for my ignorance, I am a mere
ex-fruityloops user :\
> Having an internal Filter is debatable, but if you are going to
> put it in there make sure I can modulate that to!
I've already got a low pass in there, and I'm gonna add hi/band/notch-pass
as well (and they will be modulatable). That, LFOs, and portamento
are my biggest priorities because you can create an impressive amount
of *good* music with just those tools (well, in addition to what is
already in Specimen).
> I don't want a sample editor, not even normalize or other common DSP
I'd like to think that mine is exempt, since it is only for setting
play and loop points, although I think adding the ability to draw your
ADSR (soon to become AHDSR) settings, and possibly arbitrary point
envelopes as well, would be rather slick.
> I guess now that I am thinking about it, one thing Linux people
> could (and do) do in many cases is to give me complete access to all of
> this stuff from the command line. It would be a wicked ass command but
> if I could set up a complex instrument with a script, and then play it
> without a GUI, ohhh I am drooling thinking about the weird stuff I could
> force a sampler do.
David Clark has already figured out a way to script the generation of
.beef files. It probably wouldn't be that difficult to write a
clspecimen that just takes a beef file as a command line argument,
which would be a start. But this is low priority for me. However,
LinuxSampler is designed as a console project with its own
communications protocol for parameter manipulation. It also has a lot
more design than specimen, so it might be capable of something like
what you're describing already.
More information about the linux-audio-user