Re: [linux-audio-dev] Re: EVO-Linux Physical Modeling HD Sampler

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: EVO-Linux Physical Modeling HD Sampler
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Jul 19 2000 - 01:23:32 EEST


On Tue, 18 Jul 2000, Paul Kellett wrote:
> > Would it be ok to implement a feature which when you release
> > a certain note, it starts up a new voice-set , and quickly fades
> > out the playing ones (or alternatively you can stop them abruptly) ?
>
>
> Akai samplers have a 'loop until release' mode - when the key
> is released looping is switched off so the sample continues from it's
> current position to the end. This lets you have a 'clunk' at the end
> of a sample, although if the loop is long you can't tell exactly when
> the clunk will happen (though this can be got round using another
> voice with a short silent loop at the start also in 'loop until
> release' mode.
>
> For a software sampler it's probably more easier to allow note-off
> messages to trigger samples, but 'loop until release' is
> still useful to have.

But the loop until release mode is not that easy to implement in my
streaming model.
Traditional loops are quite easy since , you can let the disk thread
just preload the stuff by following the "playlist" (the loop points).
But what happens the playback pointer is close to the loop end
and a release message arrives ?
The ringbuffer contains an addional start segment of next loop,
so in theory you could instruct the disk thread to jump to the release
section and overwrite existing buffer data.
But since we use lock-free fifos , the playback pointer can change while
you are reading , making it very difficult to figure out deltas where to put the
actual data. (I haven't investigated this issue deeply yet)

>
> __________
>
>
> > Obviously the voices will be routable through a FX section
> > (the FXes should be loadable plugins) , with dry/wet parameter.
>
>
> There are 3 ways I'd want to use plug-ins:
>
> - Global effects: with send level controls at keymap level.
> (something like a piano only needs a reverb send at patch level
> but a drum kit might want different levels on each sound).

I think my old Roland Soundcanvas had this feature:
you were able to have a drumkit with a reverberated Bassdrum
and a dry hihat.

>
> - Patch inserts: for processing all voices in a patch, for example
> compressing a drum kit.
>
> - Voice inserts: for adding functionality not included in the
> standard playback algorithm, for example ring modulation.
>
> Depending on the structure 'Bus inserts' might also be wanted for
> processing several patches.
>
> This can be represented (in the editor, and maybe in the file
> format) as a tree where inserts can be applied at any node:
>
> Output---Patch---Keymap
> | |-Keymap
> | -Keymap
> |
> |--Bus----Patch---Keymap
> | |-Keymap
> | -Keymap
> |
> -Patch---Keymap
>
>
> (Where I say keymap I mean one keymap table entry - I think concepts
> like layers should be left to the editor as the engine just wants a
> list of what conditions trigger which entries).
>
> One could also wonder if the outputs of global effects should be
> allowed to be placed anywhere in the tree so they can be processed
> by an insert, sent to a separate hardware output, etc.

Nice design
:-)

hopefully you aren't talking about recursive structures :-)

thanks for the food of thought.

Benno.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jul 19 2000 - 08:18:56 EEST