Re: [Linuxsampler-devel] Re: Gigasampler curve types

[Robert J. <rob...@da...>]

Hi,

>
> yes GMPI will be very cool, finally a free VSTi ? :-)
> I heard Steinberg is not partecipating (boycotting it ?), I guess
> because VST ist the de-facto standard and it is advantageous for them
> controlling the format possibly giving them an edge over the competition.
> Sad .... , I always heard "opensource leads to fragmentation" .... but
> to me the Windows audio world seems much more fragmented.
> VST, DirectX, RTAS, EASI, GSIF, Rewire ....
> on linux things do look much better: jack and LADSPA.
> I think an important API that is still missing is a sort of VSTi,
> would it better to extend LADSPA to support MIDI in too or is it better
> to wait for GMPI ?=20

Getting off topic but this is fun :)

MusE actually has an internal plugin interface like that. LADSPA +=20
Alsa-sequencer. It's a lightweight solution that works quite well. It has o=
ne=20
major drawback though, it can't support non-realtime rendering, not to my=20
knowledge atleast.

> I think if we had a VSTi-like API it would lead to=20
> a big proliferation of soft-synth and sampler plugins.
> But for now we have to write standalone apps that output the audio via ja=
ck
> and perform MIDI input via the ALSA interface.

I hardly know all about this so I'm probably missing a lot of intricate=20
problems... I do however have another view of this...

=46or long term (say 2-3 years from now) I think the Jack solution with sep=
arate=20
apps that talk to jackd could actually be even more powerful than a plugin=
=20
api.
What is needed however is a working session handling system that can launch=
=20
the connection graph. LADCCA is a step in the right direction, I think it=20
needs to do more though...

> (which is nice but does not offer synchronous transfer, sample accuracy
> etc)
I'm not 100% what this means, are you saying it wouldn't be possible to sol=
ve=20
this within the realms of jack ? Assuming it's not possible now...

What I see as the major reason for using plugins as opposed to jack apps is=
=20
that they require less CPU overhead. (That they are in-proc is just a=20
technicality in my opinion.)
The drawback is that there are all kinds of painful stuff that needs to be=
=20
taken into account, stability, gui-toolkits, memory handling perhaps,=20
possibly others...

Extrapolating into the future, CPU overhead (for ipc) is bound to become a=
=20
lesser and lesser problem... when CPU is no longer a problem we invent new=
=20
abstractions, in my mind Jack is such an abstraction.

An interesting question would be how much of the work that goes into GMPI=20
(which I understand has major brain power behind it ;) would be applicable =
to=20
a jack-like api ?




>
> > On Monday 03 November 2003 18.57, Mark Knecht wrote:
> > [...]
> >
> > > If the conversion is not part of LS, then what's the additional
> > > latency incurred when playing a keyboard live? How long are MIDI
> > > event's delayed going through a completely separate app? Is it
> > > deterministic, or will it vary from event to event?
> >
> > If you have an additional process that must be scheduled to process
> > every event, there is a significant risk of increased worst case
> > latency. I'm not sure how likely it is that an event is hit by two
> > "slow" reschedules (one in the MIDI processor and one in LS), but
> > it's most probably possible.
>
> Same applies to JACK but I think with a good lowlatency kernel
> the additional latency is measured in 50-100usec max.
> This means writing an ALSA user space midi router pratically does not
> degrade the MIDI timing.

Interesting. I got intrigued by this and started poking at some code last=20
night, we'll see if I can make something useful out of it.

I was thinking along the lines of a general purpose midi-filter that could =
do=20
lots of stupid stuff:
=2D velocity expand
=2D velocity compand
=2D delay
=2D arpeggio
=2D randomize
=2D split
=2D whatever

/Robert - <who is putting up his blast shield>

> I=B4ve seen keyboards that have builtin sequencers that run with a
> 500Hz (2msec period) timer and the MIDI files sound very well.
> So the ALSA user space router is absolutely not a problem.
>
> > RT-Dave, the control engineer, would assume this *will* happen
> > occasionally, effectively doubling the worst case latency, until
> > proven wrong. ;-)
>
> I=B4ll do some latency graphs with jack + jack client when adding
> jack support to LS so we can measure if direct ALSA output vs
> jack output.
> I think with the right lowlatency kernel jack output a 3msec can
> be done reliably and that is that LS needs for tight note-on response.
>
> > There most certainly will be an increase in minimum and average
> > latency, but as long as event processing is done "instantly" (by
> > blocking on input and sending the resulting events instantly; no
> > timers and stuff in the MIDI processor), that effect should be
> > insignificant. (Microseconds...)
>
> Exactly ALSA userspace MIDI routers are implemented using
> poll() so they block until a MIDI event arrives.
> This means they respond instantly (minus the context switch time)
>
> > [...]
> >
> > > On the other hand, since almost all of my MIDI goes through the
> > > Alsa stack somehow, and I view connections with kaconnect, could
> > > that be a place to put these velocity modifiers?
> >
> > Well, that was my first though when I started following this thread -
> > but unfortunately, ALSA runs only on Linux. (And QNX, though I have
> > no idea what state that stuff is in nowadays.)
>
> Don=B4t worry ALSA=B4s MIDI timing is excellent, no QNX needed.
>
> > It would be nicer IMHO, if things like the "MIDI corrector" could use
> > some portable plugin API - but OTOH, it can't be all that hard to
> > port it to various APIs. No big deal. What's important is that it
> > runs at the right place in the chain, and that it doesn't add
> > significant latency.
>
> Of course a builtin MIDI corrector is better (eg the table lookup) but
> the ALSA userspace router is ok too.
>
> Anyway it is just a waste of time discussing about the midi corrector
> stuff, we have much bigger problems, getting looping, enveloping, LFOs and
> articulation working.
>
> David: I told Christian we should implement a simple sample accurate event
> system in LS right from start because it will avoid us many troubles
> later. For example we can use the event system to do fast enveloping
> (lists of linear segments, this means sample accurate ramping and very fa=
st
> because you only need to increment the pitch value (pitch modulation)
> and/or volume value (volume modulation) by a delta amount.
> Exponential curves can be approximated by a succession of linear segments
> and you could even modulate the pitch/volume in an arbitrary way by sendi=
ng
> events with a frequency of eg. samplerate/4 which would still be very fas=
t.
>
> With current ALSA MIDI IN we cannot yet exploit the sample accurate event
> system fully but if something like VSTi for Linux comes out LS will be
> ready for sample accurate MIDI events.
> Not to mention that we can lower the current realtime MIDI IN jitter when
> LS is played live thanks of delaying the midi in events based on the
>  timestamp (we run the MIDI IN thread with higher priority than the audio
> thread thus MIDI in timing can have sub fragment-time precision).
>
> When some event code will be available in LS I=B4d like you David to revi=
ew
> it a bit since you are the timestamped-events master :-)
>
> BTW: the switch() statement seems faster than function pointers since
> it constructs a jumping table and does not need to save the return
> address on the stack.
> I think switch() will be ideal in the audio rendering routine to select
> various rendering functions, eg. sample playback with linear interpolatio=
n,
>  cubic, with and without filter etc.
>
>
> cheers,
> Benno
> http://www.linuxsampler.org
>
>
> -------------------------------------------------
> This mail sent through http://www.gardena.net
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel