linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Steve H. <S.W...@ec...>]

On Mon, Jan 20, 2003 at 10:16:30 +0100, David Olofson wrote:
> JACK client:
...
> 	- Linux still breaks JACK out-of-process latency... :-(

?

> XAP plugin:
> 	+ You don't have to worry about audio I/O.
> 	+ There is a comprehensive instrument control protocol.
> 	+ Control and audio routing and transport is integrated.
> 	+ You're running in-process, which works well on any LL kernel.
        - Doesn't exist yet ;)
        - Each point in the overall graph will be a different instance
	- Making the threading work well with all hosts will be hard
        - No way of receiving arbitary MIDI data (is that useful?)
        - No direct JACK i/o

The obvious solution is to provide the services as both XAP and JACK.

- Steve 

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Mark K. <mk...@co...>]

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> Steve Harris
> Sent: Monday, January 20, 2003 1:00 PM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> On Mon, Jan 20, 2003 at 10:18:58 -0800, Mark Knecht wrote:
> That was what we are aiming for. IIRC Evo (linuxsampler's predecesor)
> could read .gig files to some extent and streams offf disk.
>
> - Steve

Yep, I read that somewhere, at least in a goals statement. I'm new to this
guys, so I don't know the history interms of how far things got.

We've already today created almost as many messages as happened in December!
;-)

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 19.51, Mark Knecht wrote:
> > Either way, there isn't much of a real argument until XAP is
> > finalized and we have at least one host. :-)
>
> Ain't no reason to argue anyway! ;-)
>
> (And I know you guys aren't!!)

Well, as long as it's productive and people don't feel like throwing=20
fists, it's probably better called a discussion. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 19.18, Mark Knecht wrote:
> > -----Original Message-----
> > From: lin...@li...
> > [mailto:lin...@li...]On Behalf
> > Of be...@ga...
> > Sent: Monday, January 20, 2003 9:36 AM
> > To: lin...@li...
> > Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first
> > post
> >
> >
> > Perhaps it would be beneficial for all us to implement
> > LinuxSampler as a XAP plugin ? who knows ?
>
> I don't think I 'know', but I can report some data.
>
> This could work, in some applications, but (for me anyway) it might
> have limited appeal.
>
> In the GigaStudio world the sample libraries are huge, mostly
> running between 1-2GB per library. I use 10-15 of them at a time,
> so there is no way to put this in DRAM. This puts a pretty high
> stress on the underlying disk subsystem, which is fine as long as
> GSt is on it's own computer where the PCI bus and audio subsystem
> are available to do the work. So, in replacing something like GSt
> or Halion, my guess is that LinuxSampler wants to look mostly like
> a stand along application.

I see - and in that scenario, it doesn't really matter whether=20
LinuxSampler is it's own host, runs as a JACK client, or runs as a=20
XAP synth under another host. The difference is in the APIs and what=20
they provide.

Stand-alone app:
=09+ No restrictions!
=09- ...and no definitive standards. Just pick some protocols.

JACK client:
=09+ You don't have to worry about audio I/O.
=09+ Audio routing can be handled by other tools.
=09+ No lib conflicts, as you can have your own process.
=09- Linux still breaks JACK out-of-process latency... :-(
=09- There is no instrument control protocol.
=09- Control and audio run on different subsystems.

XAP plugin:
=09+ You don't have to worry about audio I/O.
=09+ There is a comprehensive instrument control protocol.
=09+ Control and audio routing and transport is integrated.
=09+ You're running in-process, which works well on any LL kernel.


(Note that these are not necessarily absolute facts. It's just based=20
on my own observations and information from the lists.)


> That said, it would be very cool to be
> able to send it control commands via the MIDI stream, or over
> Ethernet, from my main DAW. GSt doesn't support much of that today.
> (If at all...I don't use it.)

That's just a matter of the host mapping MIDI to XAP controls in a=20
useful way. What you need is a MIDI->XAP translator - and you could=20
send a custom one with LinuxSampler, to implement SysEx or whatever=20
you like. (It's just a driver/plugin, just like the interfaces to=20
ALSA, JACK and whatnot.)

Audiality implements MIDI internally for now, since it's not a=20
plugin. I just picked OSS + ALSA "rawmidi" is the control interface=20
and SDL + OSS for audio I/O, since that's what worked best for what I=20
needed at the time. (There was no XAP when I started hacking=20
Audiality, and it's still not finalized - and either way, there's no=20
host.)


> If we were looking at a trimmed down version of the technology
> which operated more like Battery, then I think that using the
> underlying sampler technology as both a plugin or a stand alone app
> running on the same DAW, if most of the samples fit in memory.
> (Easy for drums, not so easy for piano)

What exactly do you mean by "stand alone app"...?

By my definition, the only difference between a completely=20
stand-alone application and a plugin + GUI process is that in the=20
latter case, the RT thread belongs to another process.

This has no implications to users (if they even know about it!),=20
except that the latter will probably interface better with host=20
applications than will something that uses MIDI or similar in=20
parallel with JACK audio streaming.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Steve H. <S.W...@ec...>]

On Mon, Jan 20, 2003 at 10:18:58 -0800, Mark Knecht wrote:
> In the GigaStudio world the sample libraries are huge, mostly running
> between 1-2GB per library. I use 10-15 of them at a time, so there is no way
> to put this in DRAM. This puts a pretty high stress on the underlying disk
> subsystem, which is fine as long as GSt is on it's own computer where the
> PCI bus and audio subsystem are available to do the work. So, in replacing
> something like GSt or Halion, my guess is that LinuxSampler wants to look
> mostly like a stand along application.

That was what we are aiming for. IIRC Evo (linuxsampler's predecesor)
could read .gig files to some extent and streams offf disk.

- Steve

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 18.35, be...@ga... wrote:
> Hi all,
> sorry for this quiet phase, but the work at the ISP I work for
> took a month longer than expected.
> Before the end of the month it will be done thus I will finally
>  be able to get back on linuxsampler. (hopefully I'll not be
> regarded as the vaporware man because of these delays ;-) )

That used to be me, but I'm not sure I qualify any more... ;-)

(Audiality was resurrected for the third time, and inherited the code=20
from a games sound FX engine that came be by pretty much "by=20
accident", when I worked on an SDL port of the old game XKobo; Kobo=20
Deluxe. That is, I finally have something that can actually play=20
music. :-)


> Anyway in december I wrote some benchmark code and enveloping and
>  event schemes for basic building blocks (the sampler engine).
> I have not implemented this stuff in code but I have some stuff
> written on paper.

Sounds interesting. (I remember seeing something about this on LAD,=20
or somewhere.) Will you make your findings and thoughs available in=20
digital form?


> Now I see this XAP stuff from David O., it looks very cool but due
> of my scarce spare time during the last weeks I was unable to
>  read all the gigabytes of text that David and other produced.

Oops. Sorry 'bout that! ;-)


> Perhaps it would be beneficial for all us to implement LinuxSampler
>  as a XAP plugin ? who knows ?

I think it would be beneficial, provided it works at all, basically.=20
And - obviously - provided there will be usable XAP hosts before=20
LinuxSampler is mature enough for serious use.

Note that XAP plugins need to have their GUIs in separate processes,=20
to avoid GUI toolkit conflicts with the hosts! This applies to=20
in-process JACK as well, though, and shouldn't be a surprize to Un*x=20
developers. (BTW, is in-process actually implemented in JACK? Wasn't=20
last time I looked.)

Besides, I think total separation of GUI and DSP code is a good idea=20
anyway, for a number of reasons. (Stability, GUIs can be left out or=20
replaced, etc...)


> The fact that LinuxSampler's goal is to being able to user compiler
> techniques (you "draw" the signal graph on the screen , compile the
> result into C code and then run it through loading the .so module),
>  means that the API needs to be flexible and/or extensible so I
>  have currently no idea if it would be a good idea to build
> LinuxSampler on XAP internally or treat it as a black box and
> export only the audio-out channels, the MIDI-ins plus some internal
> controls.

This wouldn't be a problem. Just have the GUI do the compiling, and=20
then tell the plugin to load the .so and "mount" it. The latter is a=20
perfect job for the background worker calls I've suggested.

This isn't very different from loading patches into a normal synth or=20
sampler. There's just no way you can do it in the RT thread without=20
causing drop-outs, so you *have* to make someone do it in a separate=20
thread.

And it can't be easier than telling the host to call a function from=20
a suitable context and send you a RESULT event when the call returns,=20
can it? (Much easier than using pthreads, and - free bonus: it=20
doesn't break down when running off-line.)


> I think it will be a good idea to keep the thoughts of XAP and
>  LinuxSampler guys in sync in order to optimize both the API and
>  the sampler engine.

Yes, that's=A0what I've been thinking - but it seems that most others=20
in the XAP discussion have very little interest in plugins that don't=20
concist of 100% RT safe code... Could just be that I've failed to=20
explain the issues properly, though, or that we have so many other=20
things to worry about first.


> In a week or so I will discuss and ask for comments about my ideas
> of implementing the modular sample playback engine that uses
> compilation. One of the most interesting topics will be how we
> implement efficient event passing between the sampler's modules (eg
> two envelop generators that output to an adder module which in turn
> drives the sampler's pitch or volume.
> Being a bit of a nitpicker, I'd like to achieve sample accurate
> or near sample accurate event timing, allow dense streams of events
> (eg up to 1/4 - 1/8 samplerate) without too much performance
> penalty while retaining modularity and flexible event routing).
> It's not an easy task to solve, but my preliminary brainstorming
>  suggests me that it is possible to retain high accuracy with only
>  a few small tradeoffs.
> David is a quite good "event-hacker" so I hope that he gives us the
> right advices in order to avoid design mistakes.

Well, in fact, I'm messing with that kind of stuff right now. :-)

I've been trying to find the optimal set of events for ramped=20
controls, and Steve's suggestion to use only *one* event looks like a=20
great idea!

Next, I'll probably have the envelope generator multiply it's output=20
with incoming "scale" events, to implement click free volume and pan=20
and things like that. That is, multiplication of two ramped event=20
streams.

If all goes well, the result will be in Audiality 0.1.1, to be=20
released sometime before everyone's forgotten the name, hopefully. ;-)


> Immagine the handyness of loading an akai.so, module and start
> playing AKAI libraries with the speed of a hardcoded engine.
> The same can be said of GIG libraries.
> Fortunately the disk playback was solved a few years ago so what's
> missing is mainly some good event/modulation system, sample loading
> libriaries (swami etc) and a GUI (the proposal was
> to decouple the GUI from the engine using a TCP socket so that you
> can build headless "sampler farms" that can be controlled remotely
> from an arbitrary machine (even a TCP/IP equipped PDA :-))

With XAP, it seems like GUIs will interface to plugins through the=20
standard control system. You could think of them as XAP plugins,=20
running in their own soft RT hosts, connecting to the RT hosts=20
through an RT/non-RT gateway. No custom interfaces needed, that is.=20
The plugin<->GUI transport layer can become part of XAP.

In short, I think it's better to wrap this stuff in a XAP host SDK=20
lib, so you can use raw TCP/IP, JACK or whatnot, without rewriting=20
hosts and GUIs.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Josh G. <jg...@us...>]

On Mon, 2003-01-20 at 09:15, Mark Knecht wrote:

<cut>

> 
>    As always, I probably have too many ideas, but personally I'd really like
> to see a sample player somewhat like Battery for Linux. I think that it's a
> much more simple interface, requires far fewer system resources to work
> well, could use Wave files easily. I just think overall it would get a lot
> of use up front. The existing sample players, like iiwusynth and timidity
> are not, IMO, really very good for dealing with drum sets.
> 
>    Has there been any discussion of doing something like that?
> 

What do you find lacking with iiwusynth and drum sets? If you are
talking of creating drum sets its probably more of the patch editor that
needs to be up for this task. I have had a number of ideas in the area
of making it easier to create drum kits with Swami. I would like to know
what kinds of features you could envision for your own uses.

<cut>

> 
> Cheers,
> Mark
> 

Cheers.
	Josh Green

Things are still happening (was: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post)

[Josh G. <jg...@us...>]

On Mon, 2003-01-20 at 08:09, David Gerard Matthews wrote:
> Hey Mark,
>                 I've been on this list for a few months as well and 
> noticed it's kind of died down.  Not sure what's up with that - it was 
> very active around November, iirc.  There has been some discussion about 
> Swami, but I think the real hope for sampling under Linux might be XAP 
> (discussed extensively on linux-audio-dev.)  I also use Gigasampler a 
> bit and seeing as I'd like to dump Windoze altogether I'm hoping for a 
> way to use my libraries in Linux (like my really nifty Akai-format 
> prepared piano CD...)
> -dgm
> 
> Mark Knecht wrote:
> 

Swami is still going.. Unfortunately with just me as the developer it is
going somewhat slow. I've been a little burnt out on it lately so I'm
kind of taking a break (sometimes I find that I'm almost working on it
full time). This is hard when I realize I actually have to make money to
live (I haven't received 1 donation yet for Swami, although it hasn't
really been massively released yet.. Maybe the PayPal link is broken or
something, could someone test it? He he..). It would be cool if the
Linux audio community could actually make a living on open source
software development. We need to come up with other methods of raising
money though (grants, money pools, etc).

I already started implementing DLS2 support in libInstPatch. There is
now a generic RIFF parser that can be used for SoundFont files, DLS2 and
other RIFF based formats. The GUI is becoming more pluggable to make
plugging new formats into it rather easy (making a good API design takes
a lot of effort though).

So things are still progressing, just to assure all of you of that. I've
kept quiet because the development version is still not quite usable
(too much in development). The GTK1.2 branch works great though, and the
CVS version works with the most recent FluidSynth (well at least last
time I checked, FluidSynth is also undergoing massive API changes).

So. Keep the Linux music/audio dream alive and let everyday make it more
of a reality :) Cheers.
	Josh Green

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Benno S. <be...@ga...>]

Well, the fact that the engine is decoupled from the GUI means that
both solutions, a standalone sampler machine and the "full virtual studio in one
machine" are doable.
Regarding the stress that disk based sampling puts on the machine.
Yes it is a quite stressful application, but I don't think PCI is the
main bottleneck here.
Yes its peak performance is only 133MB/sec but as we know harddisks
usually transfer only 10-25MB/sec in the real world.
This means that you can have two separate disks one for HD recording and the
other for the sampler running in parallel without interfering too much eachother.
The problem of GS is that it is a low-level hack (requires special sound card
drivers, the sampler engine basically runs at kernel level (if it crashes =sh*t
happens :-) ) thus not very multitasking-friendly.
(especially when you want to run it in parallel with other CPU/disk hungry
software like Cubase/Logic etc).
This is why users love Halion: it is a VST plugin that can under Cubase,
 you get sample accurate processing and perfect integration, something that
the MIDI driven (even via local midi loopback) GS cannot achieve.
I have not seen GS and Halion in action side by side but from reading the
forums, when it comes to raw performance and low latency GS beats Halion because
of all these low-level hacks.
These issues coupled with the fact that Windows is not that stable when you
overload it, are (IMHO) the main reason why windows users tend to run GS
in a dedicated box treating it just like a hw device.
On the other hand  Linux's multitasking works exceptionally well and well
 designed realtime audio software can fully utilize the machine's resources
 without compromising stability.
This is why, given enough horsepower, I support the idea of the whole virtual
 studio in one single Linux box.
MIDI sequencing and a sampler/synth engine on the same box is not a problem
 since sequencing only takes a fraction of the available resources.
If you add HD recording to the equation, then the workload increases
significantly but nothing speaks against of runnning both the HDR and the
sampler software in the same box.
A single disk system is probably not up to the task because the sampler needs
to access to the data on disk and cannot easily coexist with the HDR tracks
 that fight for the same (scarce) disk bandwidth/latency.
With two disks, the focus shifts to the CPU (mixing and doing FXes on HDR tracks
 can chew up quite some CPU), but fortunately fast CPUs (2GHz+) can do both at
 the same time.
My PII400 is able to stream about 60 tracks (voices) from a 16GB IDE disk (IBM)
when using the old sampler test code. (evo), this means that with 5x the MHz
and two disks it is easily possible to do both HDR and disk based sampling on
the same box.
Regarding battery vs fully-fledged sampler: I agree, better to start out with
 something simple and elaborate later, but if we get this 
"sampler-construction-kit" done, then evolving from the simple to the
"extended" version of the sampler will take only a small amount of time since
you will basically design it using your mouse and not your editor and C compiler.
:-)
For example Juan says he prefers to first write hardcoded engines and then 
 start thinking about recompilation techniques but I see it as a bit of a waste
 of time. I prefer to take a longer
 design phase and write an engine that can later scale really high without
 the limitations of hardcoded engines.

cheers,
Benno

http://linuxsampler.sf.net
 

Scrive Mark Knecht <mk...@co...>:

> 
> In the GigaStudio world the sample libraries are huge, mostly running
> between 1-2GB per library. I use 10-15 of them at a time, so there is no way
> to put this in DRAM. This puts a pretty high stress on the underlying disk
> subsystem, which is fine as long as GSt is on it's own computer where the
> PCI bus and audio subsystem are available to do the work. So, in replacing
> something like GSt or Halion, my guess is that LinuxSampler wants to look
> mostly like a stand along application. That said, it would be very cool to
> be able to send it control commands via the MIDI stream, or over Ethernet,
> from my main DAW. GSt doesn't support much of that today. (If at all...I
> don't use it.)
> 
> If we were looking at a trimmed down version of the technology which
> operated more like Battery, then I think that using the underlying sampler
> technology as both a plugin or a stand alone app running on the same DAW, if
> most of the samples fit in memory. (Easy for drums, not so easy for piano)
> 
> I personally think a Battery like app would be a great starting point for
> this sort of technology, to be followed up by a full-blown sampler app
> later.
> 
> Cheers,
> Mark
> 
> 




-------------------------------------------------
This mail sent through http://www.gardena.net

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Mark K. <mk...@co...>]

> 
> Either way, there isn't much of a real argument until XAP is 
> finalized and we have at least one host. :-)
> 

Ain't no reason to argue anyway! ;-)

(And I know you guys aren't!!)

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 18.20, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 05:09:19 +0100, David Olofson wrote:
> > XAP is a plugin API, so it doesn't really deal with sampling or
> > any other form of synthesis directly. Linuxsampler would be very
> > useful as a XAP plugin, but that's really more of an API
> > selection matter from Linuxsampler's POV. That is, we still need
> > something to turn into a XAP plugin. :-)
>
> I think that the plans we have for linuxsampler make it a better
> inprocess jack app than a XAP plugin.

Why?

Indeed, XAP doesn't have it's own threads API for worker threads and=20
stuff, but neither does JACK, AFAIK. pthreads is fine. If XAP plugins=20
can tell if they're in a real time host or not, they can even work=20
off-line.

Anyway, XAP includes a serious instrument control API, whereas JACK=20
has no support for structured, variable rate data at all. (Yet?)

JACK + ALSA sequencer probably works. I just think it's backwards to=20
design new software around MIDI, instead of designing around a=20
standardized superset that can still interface with MIDI, and that=20
happens to be part of a plugin API.


Either way, there isn't much of a real argument until XAP is=20
finalized and we have at least one host. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 18.15, Mark Knecht wrote:
> David & David,
>    Was that the name of a band in the late 80's maybe? I must go
> look.

Well, I was just in my early teens back then, so I had nothing to do=20
with it... ;-)


>    Well, if it served no other purpose, at least my 1st posted
> created a little bit of traffic on the list, right? ;-)

Yeah, that's nice - and even Benno chimed in; long time no see! :-)


[...]
>    As always, I probably have too many ideas, but personally I'd
> really like to see a sample player somewhat like Battery for Linux.
> I think that it's a much more simple interface, requires far fewer
> system resources to work well, could use Wave files easily. I just
> think overall it would get a lot of use up front. The existing
> sample players, like iiwusynth and timidity are not, IMO, really
> very good for dealing with drum sets.

Well, I'm not very familiar with Battery, but maybe Audiality will be=20
able to do what you want rather easily? It's basically a sampler with=20
an integrated mixer. Although the primary source of waveforms is a=20
script driven off-line synth (modular synth style), it can load and=20
process audio files as well. (Which is a feature that remains from=20
Audiality's days as a games sound FX engine.)

As to UI, the scripts is as close as you get right now. There's no=20
GUI at all for it yet, but I have detailed plans for an editor.

That said, I've created almost a hundred "useful" sounds while=20
playing around with the synth. A standard text editor turns out to=20
work a lot better than I ever imagined it could! :-) (Though, my=20
previous synth programing experience is mostly with tiny LCDs and=20
buttons, and a few Windoze synth editors that only made things *more*=20
awkward.)

Anyway, Audiality is still in early beta, and there are a bunch of=20
features that need to be implemented before it's truly useful. I=20
wrote some demo songs a long time ago, so it's not *totally* useless,=20
but let's just say, the sampler part is *really* rudimentary.


[...]
>    I haven't paid too much attention to XAP as I think it's too
> much below the hood for someone like me. I'm glad to see that you
> are thinking of samplers with it. I can tell folks are interested.

We're thinking of *everything* that could process or generate audio,=20
though the primary target is synths and samplers. (We already have=20
LADSPA for effects and JACK for applications/"large scale plugins".)=20

Think of XAP as a truly Free VSTi or DXi alternative.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Mark K. <mk...@co...>]

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> be...@ga...
> Sent: Monday, January 20, 2003 9:36 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> Perhaps it would be beneficial for all us to implement LinuxSampler
>  as a XAP plugin ? who knows ?

I don't think I 'know', but I can report some data.

This could work, in some applications, but (for me anyway) it might have
limited appeal.

In the GigaStudio world the sample libraries are huge, mostly running
between 1-2GB per library. I use 10-15 of them at a time, so there is no way
to put this in DRAM. This puts a pretty high stress on the underlying disk
subsystem, which is fine as long as GSt is on it's own computer where the
PCI bus and audio subsystem are available to do the work. So, in replacing
something like GSt or Halion, my guess is that LinuxSampler wants to look
mostly like a stand along application. That said, it would be very cool to
be able to send it control commands via the MIDI stream, or over Ethernet,
from my main DAW. GSt doesn't support much of that today. (If at all...I
don't use it.)

If we were looking at a trimmed down version of the technology which
operated more like Battery, then I think that using the underlying sampler
technology as both a plugin or a stand alone app running on the same DAW, if
most of the samples fit in memory. (Easy for drums, not so easy for piano)

I personally think a Battery like app would be a great starting point for
this sort of technology, to be followed up by a full-blown sampler app
later.

Cheers,
Mark

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Mark K. <mk...@co...>]

> On Mon, Jan 20, 2003 at 09:42:04 -0800, Mark Knecht wrote:
> > Steve,
> >    I completely understand.
> >
> >    Question - the linuxsampler-gcc code I got from your server
> compiles with
> > no options in the ./configure stage, but fails when I try the
> --enable-jack
> > option. Does Jack support work for this code yet? Do I need to
> enable other
> > options to enable jack support?
>
> I dont know, you'd have to ask Juan, its his code. I've a feeling that the
> jack code is based on an old version of the API.
>
> - Steve

I just wondered if you had tried to do it. ;-)

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Steve H. <S.W...@ec...>]

On Mon, Jan 20, 2003 at 09:42:04 -0800, Mark Knecht wrote:
> Steve,
>    I completely understand.
> 
>    Question - the linuxsampler-gcc code I got from your server compiles with
> no options in the ./configure stage, but fails when I try the --enable-jack
> option. Does Jack support work for this code yet? Do I need to enable other
> options to enable jack support?

I dont know, you'd have to ask Juan, its his code. I've a feeling that the
jack code is based on an old version of the API.

- Steve 

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Mark K. <mk...@co...>]

Steve,
   I completely understand.

   Question - the linuxsampler-gcc code I got from your server compiles with
no options in the ./configure stage, but fails when I try the --enable-jack
option. Does Jack support work for this code yet? Do I need to enable other
options to enable jack support?

Cheers,
Mark

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> Steve Harris
> Sent: Monday, January 20, 2003 9:21 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> On Mon, Jan 20, 2003 at 05:09:19 +0100, David Olofson wrote:
> > XAP is a plugin API, so it doesn't really deal with sampling or any
> > other form of synthesis directly. Linuxsampler would be very useful
> > as a XAP plugin, but that's really more of an API selection matter
> > from Linuxsampler's POV. That is, we still need something to turn
> > into a XAP plugin. :-)
>
> I think that the plans we have for linuxsampler make it a better inprocess
> jack app than a XAP plugin. Several of us have other things that are more
> urgent, but we will resume work in a few* weeks.
>
> I have a couple of conferences and a gig to prepare for urgently and Benno
> and Juan have a lot of work on.
>
> * Where few is > 1 ;)
>
> - Steve
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[<be...@ga...>]

Hi all,
sorry for this quiet phase, but the work at the ISP I work for
took a month longer than expected.
Before the end of the month it will be done thus I will finally
 be able to get back on linuxsampler. (hopefully I'll not be regarded
 as the vaporware man because of these delays ;-) )

Anyway in december I wrote some benchmark code and enveloping and
 event schemes for basic building blocks (the sampler engine).
I have not implemented this stuff in code but I have some stuff
written on paper.
Now I see this XAP stuff from David O., it looks very cool but due
of my scarce spare time during the last weeks I was unable to
 read all the gigabytes of text that David and other produced.

Perhaps it would be beneficial for all us to implement LinuxSampler
 as a XAP plugin ? who knows ? 
The fact that LinuxSampler's goal is to being able to user compiler
techniques (you "draw" the signal graph on the screen , compile the
result into C code and then run it through loading the .so module),
 means that the API needs to be flexible and/or extensible so I
 have currently no idea if it would be a good idea to build LinuxSampler
 on XAP internally or treat it as a black box and export only the
 audio-out channels, the MIDI-ins plus some internal controls.

I think it will be a good idea to keep the thoughts of XAP and
 LinuxSampler guys in sync in order to optimize both the API and
 the sampler engine.

In a week or so I will discuss and ask for comments about my ideas of
implementing the modular sample playback engine that uses compilation.
One of the most interesting topics will be how we implement efficient
 event passing between the sampler's modules (eg two envelop generators
that output to an adder module which in turn drives the sampler's pitch
 or volume.
Being a bit of a nitpicker, I'd like to achieve sample accurate
or near sample accurate event timing, allow dense streams of events
(eg up to 1/4 - 1/8 samplerate) without too much performance penalty
while retaining modularity and flexible event routing).
It's not an easy task to solve, but my preliminary brainstorming
 suggests me that it is possible to retain high accuracy with only
 a few small tradeoffs.
David is a quite good "event-hacker" so I hope that he gives us the
right advices in order to avoid design mistakes.

Immagine the handyness of loading an akai.so, module and start playing
AKAI libraries with the speed of a hardcoded engine.
The same can be said of GIG libraries.
Fortunately the disk playback was solved a few years ago so what's missing
 is mainly some good event/modulation system, sample loading libriaries
(swami etc) and a GUI (the proposal was
to decouple the GUI from the engine using a TCP socket so that you can
build headless "sampler farms" that can be controlled remotely from an
 arbitrary machine (even a TCP/IP equipped PDA :-))

I know many would like quick results fast (I would like them too), but
 unfortunately a good audio engine takes time to design and we have only
 few complex open source audio projects where we can learn from.

I think the biggest near term challenge is to get the basic sampler
(with recompiler) and even system up and running.
From this point it will be easy to parallelize work so that people
can start working on sample libraries, GUIs etc, testing and improving 
the accuracy of reproduction of sample libraries etc. (filters, envelopes, 
modulators, keyzones etc)


cheers,
Benno





Scrive David Olofson <da...@ol...>:

> On Monday 20 January 2003 17.09, David Gerard Matthews wrote:
> > Hey Mark,
> >                 I've been on this list for a few months as well and
> > noticed it's kind of died down.  Not sure what's up with that - it
> > was very active around November, iirc.  There has been some
> > discussion about Swami, but I think the real hope for sampling
> > under Linux might be XAP (discussed extensively on
> > linux-audio-dev.)
> 
> Well, I'm not really involved with Linuxsampler, but I'm certainly 
> responsible for most of the bandwidth in the XAP discussion. ;-)
> 
> XAP is a plugin API, so it doesn't really deal with sampling or any 
> other form of synthesis directly. Linuxsampler would be very useful 
> as a XAP plugin, but that's really more of an API selection matter 
> from Linuxsampler's POV. That is, we still need something to turn 
> into a XAP plugin. :-)
> 
> 
> //David Olofson - Programmer, Composer, Open Source Advocate
> 


-------------------------------------------------
This mail sent through http://www.gardena.net

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Steve H. <S.W...@ec...>]

On Mon, Jan 20, 2003 at 05:09:19 +0100, David Olofson wrote:
> XAP is a plugin API, so it doesn't really deal with sampling or any 
> other form of synthesis directly. Linuxsampler would be very useful 
> as a XAP plugin, but that's really more of an API selection matter 
> from Linuxsampler's POV. That is, we still need something to turn 
> into a XAP plugin. :-)

I think that the plans we have for linuxsampler make it a better inprocess
jack app than a XAP plugin. Several of us have other things that are more
urgent, but we will resume work in a few* weeks.

I have a couple of conferences and a gig to prepare for urgently and Benno
and Juan have a lot of work on.

* Where few is > 1 ;)

- Steve

RE: [Linuxsampler-devel] Hi - Very quiet list - my first post

[Mark K. <mk...@co...>]

David & David,
   Was that the name of a band in the late 80's maybe? I must go look.

   Well, if it served no other purpose, at least my 1st posted created a
little bit of traffic on the list, right? ;-)

   From my conversation with Benno, and then just watching the discussions
on Linux-Audio-Dev, I can tell that there are a few things going on. If it's
too early, it's too early, but I wanted to simply join up and express my
interest. I'm not a software guy, so there isn't much I can do to help in
that area, but I have numerous computers and lots of interest, so when
things are ready for people like me, I'm here.

   I presume that there will be interest in supporting pre-existing
libraries. I certainly have a great desire to use the ones I own. (I'd like
a good prepared piano also!) ;-) Has any work happened to be able to open a
GSt library and get data out of it? If so, I could do testing at that level
even if the files cannot really be used right now.

   As always, I probably have too many ideas, but personally I'd really like
to see a sample player somewhat like Battery for Linux. I think that it's a
much more simple interface, requires far fewer system resources to work
well, could use Wave files easily. I just think overall it would get a lot
of use up front. The existing sample players, like iiwusynth and timidity
are not, IMO, really very good for dealing with drum sets.

   Has there been any discussion of doing something like that?

   I mentioned this to the individual that did the little SimSam player, but
haven't heard back.

   Anyway, I'll just hand out and see what happens.

   I haven't paid too much attention to XAP as I think it's too much below
the hood for someone like me. I'm glad to see that you are thinking of
samplers with it. I can tell folks are interested.

Cheers,
Mark

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> David Olofson
> Sent: Monday, January 20, 2003 8:09 AM
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Hi - Very quiet list - my first post
>
>
> On Monday 20 January 2003 17.09, David Gerard Matthews wrote:
> > Hey Mark,
> >                 I've been on this list for a few months as well and
> > noticed it's kind of died down.  Not sure what's up with that - it
> > was very active around November, iirc.  There has been some
> > discussion about Swami, but I think the real hope for sampling
> > under Linux might be XAP (discussed extensively on
> > linux-audio-dev.)
>
> Well, I'm not really involved with Linuxsampler, but I'm certainly
> responsible for most of the bandwidth in the XAP discussion. ;-)
>
> XAP is a plugin API, so it doesn't really deal with sampling or any
> other form of synthesis directly. Linuxsampler would be very useful
> as a XAP plugin, but that's really more of an API selection matter
> from Linuxsampler's POV. That is, we still need something to turn
> into a XAP plugin. :-)
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> .- The Return of Audiality! --------------------------------.
> | Free/Open Source Audio Engine for use in Games or Studio. |
> | RT and off-line synth. Scripting. Sample accurate timing. |
> `---------------------------> http://olofson.net/audiality -'
>    --- http://olofson.net --- http://www.reologica.se ---
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David O. <da...@ol...>]

On Monday 20 January 2003 17.09, David Gerard Matthews wrote:
> Hey Mark,
>                 I've been on this list for a few months as well and
> noticed it's kind of died down.  Not sure what's up with that - it
> was very active around November, iirc.  There has been some
> discussion about Swami, but I think the real hope for sampling
> under Linux might be XAP (discussed extensively on
> linux-audio-dev.)

Well, I'm not really involved with Linuxsampler, but I'm certainly=20
responsible for most of the bandwidth in the XAP discussion. ;-)

XAP is a plugin API, so it doesn't really deal with sampling or any=20
other form of synthesis directly. Linuxsampler would be very useful=20
as a XAP plugin, but that's really more of an API selection matter=20
from Linuxsampler's POV. That is, we still need something to turn=20
into a XAP plugin. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Hi - Very quiet list - my first post

[David G. M. <dg...@pi...>]

Hey Mark,
                I've been on this list for a few months as well and 
noticed it's kind of died down.  Not sure what's up with that - it was 
very active around November, iirc.  There has been some discussion about 
Swami, but I think the real hope for sampling under Linux might be XAP 
(discussed extensively on linux-audio-dev.)  I also use Gigasampler a 
bit and seeing as I'd like to dump Windoze altogether I'm hoping for a 
way to use my libraries in Linux (like my really nifty Akai-format 
prepared piano CD...)
-dgm

Mark Knecht wrote:

>Hello all,
>   A few weeks ago Benno and I were talking about something else (hardware)
>and he found out I'm a GigaStudio user. He suggested I check out the
>LinuxSampler project. He did tell me it wasn't ready for testers, however,
>if I can lend a hand early on with working on feature sets or compatibility
>with existing libraries, I'd certainly be happy to do so. I have a couple
>thousand dollars worth of GigaStudio libraries, as well as some Akai samples
>and what not. Would love to see them go under Linux.
>
>   I see this list has been quiet for about a month. That's a bit sad, but I
>understand that many other things are going on. 
>
>   I did find that Steve had put a copy of the code on his site. I
>downloaded and built it on RH 7.3. It runs, or at least it starts. I don't
>know what to do with it!!
>
>   If the action is actually elsewhere, like on Swami, then point me in the
>right direction. I'm definitely interested in seeing some sort of
>GSt/Halion/Kontact software up and running in Open Source. That would be
>great.
>
>Cheers,
>Mark
>  
>

[Linuxsampler-devel] Hi - Very quiet list - my first post

[Mark K. <mk...@co...>]

Hello all,
   A few weeks ago Benno and I were talking about something else (hardware)
and he found out I'm a GigaStudio user. He suggested I check out the
LinuxSampler project. He did tell me it wasn't ready for testers, however,
if I can lend a hand early on with working on feature sets or compatibility
with existing libraries, I'd certainly be happy to do so. I have a couple
thousand dollars worth of GigaStudio libraries, as well as some Akai samples
and what not. Would love to see them go under Linux.

   I see this list has been quiet for about a month. That's a bit sad, but I
understand that many other things are going on. 

   I did find that Steve had put a copy of the code on his site. I
downloaded and built it on RH 7.3. It runs, or at least it starts. I don't
know what to do with it!!

   If the action is actually elsewhere, like on Swami, then point me in the
right direction. I'm definitely interested in seeing some sort of
GSt/Halion/Kontact software up and running in Open Source. That would be
great.

Cheers,
Mark

[Linuxsampler-devel] Re: Linuxsampler-devel digest, Vol 1 #32 - 2 msgs

[Paul K. <pau...@ma...>]

Christian Schoenebeck <chr...@ep...> wrote:
>
> Has anybody already thought about incorporating formant manipulation into
the
> engine? That way the user would be able to e.g. pitch a sample without
> sounding synthetic. That works at least for some semi tones.
>
> And what about time stretching?


It was mentioned a long time ago (I think on linux-audio-dev) as something
that
would be nice to have, but it's probably easiest to implement for samples that
are completely in memory.

For a lot of samples, particularly drum loops where you are only going to use
one or a few shifted versions, it's more efficient to render the pitch shifted
version(s) to memory or disk rather than calculate them live.  It then becomes
a job for the interface rather than for the real-time engine.

Interactive pitch/formant shifting (like the Roland VariPhrase and Native
Instruments Kontakt) probably needs to have an intermediate "analysis" file
created, which is what gets played back.  One way to handle this would be
if the engine could use custom "renderers" for particular file types.

The technology for pitch and formant shifting is known (usually LPC analysis,
inverse filtering to flatten the spectrum, pitch shifting by crossfading
between buffers (pitch synchronously if the audio is monophonic) then
filtering
to re-apply the spectrume shape, or a shifted version of it) but is just a lot
of work for someone to get it sounding good.  Probably what is important at
this
stage is to make sure the engine can cope with this sort of thing in the
future.


Paul.

_____________________________

  m a x i m | digital audio

    http://mda-vst.com
_____________________________

[Linuxsampler-devel] Formant manipulation

[Christian S. <chr...@ep...>]

Has anybody already thought about incorporating formant manipulation into the 
engine? That way the user would be able to e.g. pitch a sample without 
sounding synthetic. That works at least for some semi tones.

And what about time stretching?

Regards, 
Christian

Re: [Linuxsampler-devel] evo code

[Christian S. <chr...@ep...>]

Es geschah am Mittwoch, 11. Dezember 2002 23:08 als Benno Senoner schrieb:
> > > This check can be moved within the disk thread which accesses the
> > > buffer with a much lower frequency and where it is easy to figure out
> > > when the last read reached the ring buffer end position.
> >
> > I'm not sure what you're getting at. Do you mean that it's more likely
> > that read/write access to the buffer won't interfere/overlap, because the
> > audio thread reads faster than the disk buffer can fill up the space, due
> > to the higher priority of the audio thread?
>
> no, the disk thread "always writes faster than the audio thread reads",
> or in short: there will be always some data in the ring buffer as long
> as the disk is not overloaded (if that happens we must lower the max #
> of voices or user more powerful hardware ... it is not our fault).

Oh, I expressed myself wrong. Anyway, I think I got the idea.

Thanks!