Re: [Linuxsampler-devel] Suupporting various sample library formats and engines

[[3] <ma...@ve...>]

heh. thanks
Steve Harris wrote:

>[Peter, I'm assuming you meant to mail this to the list, I'm replying to
> the list anyway ;)]
>
>As discussed on IRC last night, the problem is that some sample formats
>have features that can't easily be implemented with a disk based generic
>engine, for example the AKAI sample format allows you to vary the start
>point with note on velocity (though I dont know by how much). I think that
>some hardware samplers allow you to modulate the loop points in realtime,
>though the 3000 series AKAIs cannot aparently.
>
wouldn't you be better off loading those samples straight into memory?

>
>So, I think it is better to have seperate sub-engines that communicate
>with the main engine at a high level (eg. to the sub-engine: "Here is a
>bunch of event data ...", from the sub-engine: "I want 8 outputs", "here
>is a lump of audio data ...").
>
mmm...

>
>Though obviously data transfer would be callback based or something.
>
>The alternative would be to normalise all the sample formats into one,
>grand unified sample format and just handle that (I believe that is how
>gigasampler works?).
>
>
>I suspect that is less efficient though, and it doesn't allow for
>specific support for styles of sample playback.
>
amen brother...

>
>I think it mould make sense to preparse the event data, rather than trying
>to handle raw midi. Mayeb using something like the OSC event stream?
>
>anyone know of other preparsed event formats?
>

..snip

cheers   
    [3]
    ma...@ve...