Subject: Re: [linux-audio-dev] Re: EVO-Linux Physical Modeling HD Sampler
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Jul 18 2000 - 19:17:48 EEST
On Tue, 18 Jul 2000, David Olofson wrote:
> > - loop point begin , loop point end
> > - oneshot / looped
>
> Although you can do most things you want with this, multiloops (ie a
> list of regions, rather than a single loop) may be worth
> investigating...
yeah, I thought about this , but it may be quite tricky to implement,
because the audio thread has to instruct the disk thread where to
preload.
In theory the disk thread could work it's own and just follow the "playlist"
His goal is to keep the ringbuffer full and he can do this by following
the loop points described in the voice structure.
The problem arises when let's say the starting point of the loop is in the
initial preloaded RAM area (which is mlocked), and the end point
resides after this area.
But I think the simplest solution to this is simply letting check the diskthread
the requested playback offset, and if it resides in RAM , then instead of
filling the ringbuffer using read()s , just memcpy() from the RAM are into the
ringbuffer, and the audio thread will not notice that we cheated.
Simple solution and alway faster than reading from disk :-)
It will cause a a bit of memory pingpong for a very small period of time,
but it will ensure that the audio and the disk thread never get out of sync.
The overhead of this is negligible.
(hehe got this idea just while writing this mail :-) )
>
> > - base volume
> > - base pitch
> > - base panorama (balance)
> > - base filter cutoff
> > - base filter resonance
>
> Filter types?
the ones where source code is available :-)
any good pointers ?
I have a 24dB resonant lowpass I found on comp.dsp
long time ago (sounds quite ok),
and a guy on music-dsp just posted another one a few
days ago
(12dB LP with resonance)
>
> With quadratic splines:
>
> validity in number of samples
> starting value
> delta per sample
> delta change per sample
yea I forgot that we can aproximate any polinomial
with the finite differences.
I think we should support two types:
- linear slopes
- cubic splines
with cubic splines you can aproximate arbitrary curves
VERY accurately.
And considering that is needs only two more additions
compared to the linear case, then it is really CHEAP.
:-)
>
> There's another problem here, though; envelope timing may need to be
> scaled along with pitch and other things.
this IS a problem: the validity is given in num of samples so it has to be an
integer.
But in theory you could use a float value, and decrement in non integer steps.
As soon numsamples gets <= 0 load the new dataset,
check the fractional part and apply linear/cubic interpolation between the two
points.(this happens only between two envelope segments)
Should produce quite smooth curves.
Does this make sense ?
>
> [...]
> > Another thing we could do is to map a MIDI controller
> > to different envelope structures, so that
> > differen controller values (the modwheel or breath-controller)
> > could for example change the attack behaviour of the sample
> > at the next note trigger.
> > (would this feature be useful ?)
>
> This could be a way to solve the issue mentioned above. No big
> problem with data size, and editors can generate the timestretched
> envelopes when saving the files. How to load them back into something
> editable, though...?
Yes this mapping is quite easy to implement, but would my proposed
real-time envelope stretching make sense ?
eg. stretching and expanding pitch envelopes using LFOs ,
are we in the FM domain now .... ?
:-)))
>
> > Obviously the voices will be routable through a FX section
> > (the FXes should be loadable plugins) , with dry/wet parameter.
>
> Better do this real. There are at least 4 standard MIDI CCs for
> effect send levels, two of which are supported by most synths and
> samplers with built-in FX. Two is pretty restrictive for a full
> arangement, considering that a really good sampler should be able to
> handle *all* sounds in many kinds of arrangements, so at the very
> least, the 4 standard sends should be implemented. Preferably
> something more powerful and more generic.
How about using LADSPA to load plugins, and let the sampler map
MIDI CCs to LADSPA controls ?
My voice structure is already prepared for flexible routing because the
audiovoice class has its own output pointers.
So you can basicallly send your data where you want.
>
>
> Finally, don't regard MIDI as the True Model to design the sampler
> around! MIDI has too low controller resolution, no timestamps, only
> 16 channels/port, only pitch + velocity data inside NoteOn events etc
> etc... Not that I'm expecting MIDI to be replaced any time soon, but
> at least, accepting the *figures* defined by MIDI as the measures for
> how many Fx sends there should be and that kind of stuff might result
> in somewhat illogical restrictions. Adopt the MIDI implementation
> (CC, BC and PC mapping for example) to the sampler rather than the
> other way around, within sensible limits. Just something to consider
> before hardcoding MIDI into the engine core forever, perhaps.
BTW: CC is continuous controller , but what is BC and PC ?
I agree MIDI is not the best in the world, but for now we have to live with it.
My code does not depend heavily on MIDI:
the only part which depends on MIDI is the midithread which sends events
to the audio engine and the note-on , note-off receive parts.
Internally I use my own structures for instruments , voices, samples,
patches (not ready yet).
For example there is no concept of MIDI channel yet.
When it will be added, it will simply map one or more MIDI channel to an
instrument.
Benno.
This archive was generated by hypermail 2b28 : Wed Jul 19 2000 - 08:19:05 EEST