Menu
▾
▴
linuxsampler-devel
|
From: Mark K. <mk...@co...> - 2003-01-20 18:10:29
|
> 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. ;-) |
|
From: David O. <da...@ol...> - 2003-01-20 18:47:24
|
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 --- |
|
From: Mark K. <mk...@co...> - 2003-01-20 18:53:03
|
> > 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!!) |
|
From: David O. <da...@ol...> - 2003-01-20 21:18:29
|
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 --- |
|
From: <be...@ga...> - 2003-01-20 17:35:33
|
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 |
|
From: Mark K. <mk...@co...> - 2003-01-20 18:20:11
|
> -----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 |
|
From: Benno S. <be...@ga...> - 2003-01-20 18:54:44
|
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 |
|
From: David O. <da...@ol...> - 2003-01-20 22:23:41
|
On Monday 20 January 2003 19.54, Benno Senoner wrote: > 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. Exactly - and using an API that handles both audio and sample=20 accurate control would make it easier to get right and more robust, I=20 think. > 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. Yes - but if you have a phatt array of drives, PCI won't cut it. I=20 guess that's why mid and high end servers, and even workstations come=20 with 64 bit PCI and stuff. > 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. BTW, there's a problem if you need HDR and direct-from-disk sampling=20 at the same time. (Which I would all the time, if I used a disk=20 sampler, since I never record synth stuff to disk before vocals. I=20 like to have full control until the final mixdown.) Obviously, you can just use three disks; one for the system, one for=20 the sampler and one for the HDR. However, if you use more than one=20 disk sampler at a time, this starts getting out of hand... This is why I suggested a standard disk butler API on LAD - but I=20 think we need to do a lot more thinking and coding before turning=20 that into a standard. Maybe something useful will eventually take=20 form in the internals of LinuxSampler, so we can design a XAP=20 extension around that, rather than guessing. > The problem of GS is that it is a [...] So, in short, GS is a Windows specific performance hack, while Halion=20 is a plugin sampler Done Right - only on the wrong OS. > 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. Yes - although I think Paul has pointed out that there are still=20 issues with the scheduler when pushing it as hard as JACK does. IIRC,=20 it sometimes doesn't schedule the right process. Seems obvious that=20 this should be fixed in 2.5, but until then... > This is why, given enough horsepower, I support the idea of the > whole virtual studio in one single Linux box. =2E..and with 2 or more P-4 or better CPUs, preferably utilizing SIMD,=20 we're looking at some *serious* DSP power... > 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. Except that they need separate disks, unless they share the disk=20 butler, I think... Just adding another disk would probably be=20 acceptable to most serious users, though. [...] > 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. Well, as long as you actually get through the design phase without=20 killing the project, spending more time on the design sounds like a=20 good idea. Saves time in the long run, provided you think straight=20 and know what you're doing. That said, I did it the other way around with Audiality. (Which is=20 effectively a working test bed for my XAP ideas, BTW.) It's also the=20 first major spare time project of mine that's really off the ground.=20 It's been more or less fully functional right from the start=20 (although it didn't do much :-), almost 2 MB of code ago. I've just=20 added features as I needed them (ehrm, or just thought they would be=20 fun to play with), and restructured when things started getting too=20 messy. Note that this restructuring part is *very* important, but usually=20 really rather boring. I believe the only reason why Audiality isn't a=20 total heap of spaghetti is that I have trouble remembering complex=20 APIs and logic. If it's to messy, I just can't work with it and must=20 fix it. Obviously, there's a great deal of rewriting and moving stuff around=20 in this process, but that's not all bad. I've actually *tried* the=20 solutions that I ruled out, and when I get a new "great idea", I can=20 just test it and see if it actually works. When it comes to design,=20 testing ideas in a real app is a lot more useful than testing in a=20 fake environment. Often, you realize where you went wrong as soon as=20 you start typing the test code. What I'm saying is that the "hack away" approach may not be the most=20 effective way of creating software, but it sure beats never getting=20 off the ground. I think this all boils down to "It's more fun to hack=20 something that sort of works." If it doesn't compile, run and do=20 something "interesting" every 10-20 hours of hacking or so, you're in=20 trouble... Can't tell you what to do, but given my experience, I would say Juan=20 has a point. Though, it seems to me that rudimentary C code=20 generation shouldn't have to be *that* complicated. You could=20 probably fake most of it, and basically just have the engine output,=20 compile and load a hand coded voice struct, until you have the real=20 stuff in place. //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 --- |
|
From: Mark K. <mk...@co...> - 2003-01-20 23:58:40
|
> > > > The problem of GS is that it is a > [...] > > So, in short, GS is a Windows specific performance hack, while Halion > is a plugin sampler Done Right - only on the wrong OS. > > Ah, but GS has the library that the other's wish they had. (And that I've already invested a couple grand in, so let's not get religious and go some other direction! There would be huge value in being able to load GSt libraries into ANYTHING we do. GSt crashes all the time when running on a PC with other apps. It's actually pretty stable on it's own machine. > > 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. > > Except that they need separate disks, unless they share the disk > butler, I think... Just adding another disk would probably be > acceptable to most serious users, though. > There's a lot going on these days on the sequencer side with notation. I expect that I will run 2-3 computers to really do what I want to do, but that's me. I can already bring my disks to their knees just running Ardour. I doubt my current, sub-2GHz Athlon XP would run this sampler at the level I push GSt, which is 10-15 stereo libraries and maybe 100 voices sustained over time. Hans Zimmer, doing movie scores, has talked of pushing multiple copies of GSt to the level of 300-500 voices sustained. Those guys are using arrays of SCSI drives. It can be a lot bigger than just another drive. |
|
From: David O. <da...@ol...> - 2003-01-21 01:49:08
|
On Tuesday 21 January 2003 00.57, Mark Knecht wrote: > > > The problem of GS is that it is a > > > > [...] > > > > So, in short, GS is a Windows specific performance hack, while > > Halion is a plugin sampler Done Right - only on the wrong OS. > > Ah, but GS has the library that the other's wish they had. (And > that I've already invested a couple grand in, so let's not get > religious and go some other direction! There would be huge value in > being able to load GSt libraries into ANYTHING we do. Well, I was talking about software design - not file formats. Of=20 course, LinuxSampler should load and play *anything*! :-) > GSt crashes all the time when running on a PC with other apps. It's > actually pretty stable on it's own machine. That's to be expected when abusing an OS like that, it seems... And=20 that's why I gave up on audio programming on Windoze a few years ago. > > > 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. > > > > Except that they need separate disks, unless they share the disk > > butler, I think... Just adding another disk would probably be > > acceptable to most serious users, though. > > There's a lot going on these days on the sequencer side with > notation. I expect that I will run 2-3 computers to really do what > I want to do, but that's me. Well, I use two with Audiality, because I have yet to find a Linux=20 sequencer that I can compile, that does what I need, and that doesn't=20 get on my nerves. Still using Cakewalk on Windoze, that is. (Although=20 that's getting on my nerves as well - and not only for political=20 reasons! *heh*) > I can already bring my disks to their knees just running Ardour. I > doubt my current, sub-2GHz Athlon XP would run this sampler at the > level I push GSt, which is 10-15 stereo libraries and maybe 100 > voices sustained over time. Hans Zimmer, doing movie scores, has > talked of pushing multiple copies of GSt to the level of 300-500 > voices sustained. Those guys are using arrays of SCSI drives. It > can be a lot bigger than just another drive. Sounds like they have some serious seeking overhead there... I had 16=20 stereo tracks playing on a 5 GB 5400 rpm drive under Windoze 3.11, so=20 I know for a fact that it's possible to get at least 60% of the=20 nominal sustained rate of the drive. IIRC, I used 400 kB of buffering=20 per track for that, and you need to multiply that with the number of=20 tracks to keep the seeking overhead constant. That is, 800 kB for 32=20 tracks, or 8 MB (!) for 320 tracks. Yes, this is *per track* buffer=20 size. Indeed, SCSI disks are generally faster when it comes to access=20 times, but not *that* much faster. RAID arrays (with the same data on=20 all disks) only divide average access times by the number of drives,=20 or something like that. //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 --- |
|
From: Steve H. <S.W...@ec...> - 2003-01-20 21:00:48
|
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 |
|
From: Mark K. <mk...@co...> - 2003-01-20 21:29:16
|
> -----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! ;-) |
|
From: David O. <da...@ol...> - 2003-01-20 21:16:46
|
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 --- |
|
From: Steve H. <S.W...@ec...> - 2003-01-20 21:43:04
|
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
|
|
From: David O. <da...@ol...> - 2003-01-20 22:53:03
|
On Monday 20 January 2003 22.41, Steve Harris wrote: > On Mon, Jan 20, 2003 at 10:16:30 +0100, David Olofson wrote: > > JACK client: > > ... > > > =09- Linux still breaks JACK out-of-process latency... :-( Seems to be a scheduler issue, but I don't have first hand experience=20 with this. I don't know if it's been fixed yet, but Paul have been=20 complaining about it every now and then. > > 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. > > - Doesn't exist yet ;) That's a point! :-) > - Each point in the overall graph will be a different > instance Yes, but that applies to JACK and applications as well. I don't see=20 what you mean. > - Making the threading work well with all hosts will be > hard Possibly. Do you have some details on this? (Conflicts with what the=20 host is doing or whatever.) > - No way of receiving arbitary MIDI data (is that useful?) It's not useful for normal stuff, since you can map all RT MIDI=20 events to XAP events one way or another through a standard=20 driver/translator plugin. In fact, you can even pipe SysEx through=20 XAP (as data controls), so there might just not be a need for MIDI at=20 all; just a standard way of passing "non-standard" stuff to plugins,=20 if they want it. (You'd just have input ports for SysEx if you want=20 it.) > - No direct JACK i/o Why would you need that if you're a XAP plugin? It's the host that=20 decides where your audio ports are connected. That's one of the few=20 really significant differences between JACK and LADSPA, XAP, VST etc. > The obvious solution is to provide the services as both XAP and > JACK. Yes... Although I don't see why you couldn't provide your own=20 JACKified XAP host that automatically loads and hooks up=20 LinuxSampler. XAP would just be the native API of the synth - wrap as=20 you like, using standard or custom wrappers. Or you could just make the sampler a lib with whatever interface you=20 like, and then implement "wrappers" for JACK, XAP, VST or whatever.=20 Not sure I see the point in designing your own private API just for=20 that, though. I was going to do something like that with Audiality, but haven't=20 decided how to do it yet. I might just make it a XAP plugin, as XAP=20 and Audiality internals have lots in common anyway. There will still=20 be an easy to use "games sound engine" style API as well, but that=20 could be implemented as a specialized XAP host for Audiality (or=20 maybe even a "real" XAP host), rather than Audiality itself. //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 --- |
|
From: Steve H. <S.W...@ec...> - 2003-01-20 23:46:26
|
On Mon, Jan 20, 2003 at 11:52:47 +0100, David Olofson wrote: > > > - Linux still breaks JACK out-of-process latency... :-( > > Seems to be a scheduler issue, but I don't have first hand experience > with this. I don't know if it's been fixed yet, but Paul have been > complaining about it every now and then. Oh, I see, thats not specific to JACK, it affects all SCHED_FIFO programs. The intention is that linuxsampler wil be inprocess anyway. > > - Each point in the overall graph will be a different > > instance > > Yes, but that applies to JACK and applications as well. I don't see > what you mean. No, beacuse a JACK application can export ports to all other jack applications, whereas a plugin is only available to its host app. > > - Making the threading work well with all hosts will be > > hard > > Possibly. Do you have some details on this? (Conflicts with what the > host is doing or whatever.) Nothing concrete, but I can imagine how hard it would be to get it working reliably in LADSPA and this isnt really any different. > > - No direct JACK i/o > > Why would you need that if you're a XAP plugin? It's the host that > decides where your audio ports are connected. That's one of the few > really significant differences between JACK and LADSPA, XAP, VST etc. The JACK audio routing system is just more powerful than plugin hosting. Obviously you need that too, but for something as potentially sophisticated as a sampler I'd really want it available drectly to JACK. More layers of overheard and shims would kinda defeat the point. - Steve |
|
From: David O. <da...@ol...> - 2003-01-21 00:19:57
|
On Tuesday 21 January 2003 00.45, Steve Harris wrote: > On Mon, Jan 20, 2003 at 11:52:47 +0100, David Olofson wrote: > > > > =09- Linux still breaks JACK out-of-process latency... :-( > > > > Seems to be a scheduler issue, but I don't have first hand > > experience with this. I don't know if it's been fixed yet, but > > Paul have been complaining about it every now and then. > > Oh, I see, thats not specific to JACK, it affects all SCHED_FIFO > programs. Yes, it's a general RT issue that just happens to impact JACK more=20 than single RT thread apps. I wasn't very clear. > The intention is that linuxsampler wil be inprocess > anyway. But can you do that with JACK at this point? (Haven't checked lately.) > > > - Each point in the overall graph will be a different > > > instance > > > > Yes, but that applies to JACK and applications as well. I don't > > see what you mean. > > No, beacuse a JACK application can export ports to all other jack > applications, whereas a plugin is only available to its host app. Ah, I see. So, if the XAP plugin runs in a JACKified host, where's=20 the difference? Also, I don't see how using multiple instances could=20 change this. They would just be independent samplers, possibly=20 sharing the disk butler, if that runs as a separate process. > > > - Making the threading work well with all hosts will be > > > hard > > > > Possibly. Do you have some details on this? (Conflicts with what > > the host is doing or whatever.) > > Nothing concrete, but I can imagine how hard it would be to get it > working reliably in LADSPA and this isnt really any different. Well, I don't really see any problems beyond getting the=20 sampler/butler interaction to work right. You still have an RT part=20 (the "official" plugin) and one or more lower priority worker threads. > > > - No direct JACK i/o > > > > Why would you need that if you're a XAP plugin? It's the host > > that decides where your audio ports are connected. That's one of > > the few really significant differences between JACK and LADSPA, > > XAP, VST etc. > > The JACK audio routing system is just more powerful than plugin > hosting. In what way? Isn't the only significant difference that the=20 connections are made by clients rather than a host? It's still block based I/O. There is audio in your input buffers when=20 you get woken up or called, and there should be audio in your output=20 buffers before you signal back or return. You can have NULL buffers=20 and whatnot to optimize silence with both schemes, of course. > Obviously you need that too, but for something as > potentially sophisticated as a sampler I'd really want it available > drectly to JACK. More layers of overheard and shims would kinda > defeat the point. Well, I have problems seeing where the overhead is, when you're still=20 dealing with buffers of float32 samples all over the place, but I'm=20 probably missing something. You'll need wrappers or other solutions=20 in one direction or another, no matter what the lowest level API is -=20 unless you support only one API, of course. //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 --- |
|
From: Steve H. <S.W...@ec...> - 2003-01-21 09:32:32
|
On Tue, Jan 21, 2003 at 01:19:42 +0100, David Olofson wrote: > > Oh, I see, thats not specific to JACK, it affects all SCHED_FIFO > > programs. > > Yes, it's a general RT issue that just happens to impact JACK more > than single RT thread apps. I wasn't very clear. No, it just shows up in jack because thats the only useful way to run multiple SCHED_FIFO applications! > > The intention is that linuxsampler wil be inprocess > > anyway. > > But can you do that with JACK at this point? (Haven't checked lately.) Well yes, the alsa_driver is inprocess. There is some support for loading application inprocess at runtime, but its not 100%. > > Nothing concrete, but I can imagine how hard it would be to get it > > working reliably in LADSPA and this isnt really any different. > > Well, I don't really see any problems beyond getting the > sampler/butler interaction to work right. You still have an RT part > (the "official" plugin) and one or more lower priority worker threads. Well, the butler /is/ the problem. > > The JACK audio routing system is just more powerful than plugin > > hosting. > > In what way? Isn't the only significant difference that the > connections are made by clients rather than a host? A JACK app can connect directly to physical i/o, and can connect to any ported part of another application. A XAP instance is limited to the connections that can be provided by the host application. The behaviour of a hardware sampler leads me to think of it more like a jack application than a plugin. Thats not to say that I dont think a sampler plugin is useful, obviously it is, but I think a JACK sanmpler is more useful. > > Obviously you need that too, but for something as > > potentially sophisticated as a sampler I'd really want it available > > drectly to JACK. More layers of overheard and shims would kinda > > defeat the point. > > Well, I have problems seeing where the overhead is, when you're still > dealing with buffers of float32 samples all over the place, but I'm > probably missing something. You'll need wrappers or other solutions > in one direction or another, no matter what the lowest level API is - > unless you support only one API, of course. Well as XAP and JACK are fundamentally callback based you can provide common source with just the control handling that isn't shared. It isn't neccesary to have all the XAP host cruft (VVIDs, events, blah, blah) between jack and the sampler code. - Steve |
|
From: David O. <da...@ol...> - 2003-01-21 15:30:35
|
On Tuesday 21 January 2003 10.31, Steve Harris wrote: > On Tue, Jan 21, 2003 at 01:19:42 +0100, David Olofson wrote: > > > Oh, I see, thats not specific to JACK, it affects all > > > SCHED_FIFO programs. > > > > Yes, it's a general RT issue that just happens to impact JACK > > more than single RT thread apps. I wasn't very clear. > > No, it just shows up in jack because thats the only useful way to > run multiple SCHED_FIFO applications! Well, most people aren't using SCHED_FIFO for RT prototyping of RTAI=20 or RTL applications, so that's a point... :-) [...] > > > Nothing concrete, but I can imagine how hard it would be to get > > > it working reliably in LADSPA and this isnt really any > > > different. > > > > Well, I don't really see any problems beyond getting the > > sampler/butler interaction to work right. You still have an RT > > part (the "official" plugin) and one or more lower priority > > worker threads. > > Well, the butler /is/ the problem. Of course - it's a worker thread, and the plugin needs to communicate=20 with it without screwing other stuff up. Apart from obvious resource=20 sharing conflicts (signals, maybe), it seems to me that it would be=20 little more than a matter of picking a suitable priority for the=20 butler thread. What am I missing? > > > The JACK audio routing system is just more powerful than plugin > > > hosting. > > > > In what way? Isn't the only significant difference that the > > connections are made by clients rather than a host? > > A JACK app can connect directly to physical i/o, and can connect to > any ported part of another application. So can a XAP plugin - only it's actually the host that decides and=20 makes the connection. After all, what you get is still an audio=20 buffer that you're supposed to read or write once per block cycle. I=20 still don't see why it would matter what API(s) are used to get=20 access to the buffers. > A XAP instance is limited > to the connections that can be provided by the host application. Yes, and the way I see it, that's *intended*. When you're using a=20 host app, the host app is responsible for connections with the=20 outside world. (The only exception would be "driver plugins", which=20 interface the RT net with JACK, ALSA and other APIs.) If the host=20 doesn't allow the user to make the desired connections, the host is=20 broken and/or not the right tool for the job. =46rom the user POV, the only difference is that the JACK version would=20 integrate I/O selection in the LinuxSampler UI, while the XAP version=20 would rely on the host UI for that. Is that a problem? > The behaviour of a hardware sampler leads me to think of it more > like a jack application than a plugin. Thats not to say that I dont > think a sampler plugin is useful, obviously it is, but I think a > JACK sanmpler is more useful. What behavior are you referring to? Seriously, I want XAP plugins to=20 behave as much like real hardware as is possible and desirable. I=20 think there is a design issue with XAP if it can't host a sampler=20 properly. > > > Obviously you need that too, but for something as > > > potentially sophisticated as a sampler I'd really want it > > > available drectly to JACK. More layers of overheard and shims > > > would kinda defeat the point. > > > > Well, I have problems seeing where the overhead is, when you're > > still dealing with buffers of float32 samples all over the place, > > but I'm probably missing something. You'll need wrappers or other > > solutions in one direction or another, no matter what the lowest > > level API is - unless you support only one API, of course. > > Well as XAP and JACK are fundamentally callback based you can > provide common source with just the control handling that isn't > shared. Exactly. > It isn't neccesary to have all the XAP host cruft (VVIDs, > events, blah, blah) between jack and the sampler code. Right, but you still need a control interface. And it should probably=20 be sample accurate and support ramping, even if the first priority is=20 driving it from MIDI. If you use the ALSA sequencer API directly, you'll have to provide an=20 alternative interface anyway, since ALSA sequencer doesn't make much=20 sense for the XAP plugin. If you use your own custom control=20 interface, you need to wrap it with custom code for *both* JACK and=20 XAP. Using XAP, no extra work is needed for the XAP version (obviously),=20 and you could just use a standard or custom MIDI->XAP=20 driver/converter (which is one of the first things I'll implement, as=20 I still need MIDI to do anything useful) together with LinuxSampler=20 when running it as a JACK client. Using XAP as your "custom" API makes a lot of sense to me. If it's=20 too complex to be a viable solution for that, I'm suspecting that we=20 need to do some cleaning up. It's really supposed to be about as=20 clean and simple as possible, while providing what you need for=20 instrument control. If it's not suitable for a sampler, I think we=20 might be on the wrong track. What I'm saying is that XAP is *intended* for this kind of stuff. If=20 it doesn't fit, we'll have to make it fit, or there's just no point=20 in having it. //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 --- |
|
From: Steve H. <S.W...@ec...> - 2003-01-21 17:09:31
|
On Tue, Jan 21, 2003 at 04:30:18 +0100, David Olofson wrote: > > A JACK app can connect directly to physical i/o, and can connect to > > any ported part of another application. > > So can a XAP plugin - only it's actually the host that decides and > makes the connection. After all, what you get is still an audio > buffer that you're supposed to read or write once per block cycle. I > still don't see why it would matter what API(s) are used to get > access to the buffers. So, in other words, it can't ;) The idea is that the sampler should be able to connect to hardware inputs from its UI in order to sample. From within XAP you cant do that. I hope. Its not really a plugin UI feature and if it was present it would be bloat. > > The behaviour of a hardware sampler leads me to think of it more > > like a jack application than a plugin. Thats not to say that I dont > > think a sampler plugin is useful, obviously it is, but I think a > > JACK sanmpler is more useful. > > What behavior are you referring to? Seriously, I want XAP plugins to > behave as much like real hardware as is possible and desirable. I > think there is a design issue with XAP if it can't host a sampler > properly. XAP can host a sampler properly, its just not /ideal/. If it was ideal it would be JACK. There are two use cases (it seems, from the windows world), samplers as applications (gigasampler, ie. linuxsampler under JACK), and as plugins (Halion and friends, ie linuxsample under XAP). I think that the application model gives you more power and control, but both are useful. - Steve |
|
From: David O. <da...@ol...> - 2003-01-21 17:31:49
|
On Tuesday 21 January 2003 18.08, Steve Harris wrote: > On Tue, Jan 21, 2003 at 04:30:18 +0100, David Olofson wrote: > > > A JACK app can connect directly to physical i/o, and can > > > connect to any ported part of another application. > > > > So can a XAP plugin - only it's actually the host that decides > > and makes the connection. After all, what you get is still an > > audio buffer that you're supposed to read or write once per block > > cycle. I still don't see why it would matter what API(s) are used > > to get access to the buffers. > > So, in other words, it can't ;) Right; it can't *make* the connection, but it can handle the=20 connection, once it's made. > The idea is that the sampler should > be able to connect to hardware inputs from its UI in order to > sample. From within XAP you cant do that. I hope. Its not really a > plugin UI feature and if it was present it would be bloat. Agreed. That said, the sampler being a XAP plugin doesn't prevent it's GUI=20 from being unaware of the difference between running as a XAP plugin=20 and running as a JACK client. When doing the latter, just make the=20 I/O selection features available. Nothing says that the GUI must talk=20 *only* to the sampler plugin when running as a JACK client. > > > The behaviour of a hardware sampler leads me to think of it > > > more like a jack application than a plugin. Thats not to say > > > that I dont think a sampler plugin is useful, obviously it is, > > > but I think a JACK sanmpler is more useful. > > > > What behavior are you referring to? Seriously, I want XAP plugins > > to behave as much like real hardware as is possible and > > desirable. I think there is a design issue with XAP if it can't > > host a sampler properly. > > XAP can host a sampler properly, its just not /ideal/. If it was > ideal it would be JACK. > > There are two use cases (it seems, from the windows world), > samplers as applications (gigasampler, ie. linuxsampler under > JACK), and as plugins (Halion and friends, ie linuxsample under > XAP). > > I think that the application model gives you more power and > control, but both are useful. Yes, I see what you mean now. However, I don't think the API used for=20 the RT part of the sampler matters. When you want to record, just=20 grab audio from one or more inputs. If the GUI knows you're running=20 as a JACK client, it can let the user connect the inputs. If not, the=20 user will have to do that with the plugin host. Where's the problem? //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 --- |
|
From: David O. <da...@ol...> - 2003-01-20 20:50:34
|
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 --- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X