Menu
▾
▴
linuxsampler-devel
|
From: Christian S. <chr...@ep...> - 2003-03-13 12:56:29
|
Sorry guys for being impatient, but is there any progress at all or are you all too busy to work on this project? As nobody answered if and how I could participate in this project, I just can make a suggestion to e.g. write an Akai and / or Gigasampler import module, as I haven't seen that anyone's working on it yet. But due to my impatience and demand to be able to use my Gig and Akai library again (unfortunately I already sold my Akai sampler *sigh*) I already considered starting to write a usable sample engine on my own in case this project can be considered as dead. How about you Mitchell? Regards, Christian |
|
From: Mark K. <mk...@co...> - 2003-03-13 14:45:18
|
> Sorry guys for being impatient, but is there any progress at all or are > you all too busy to work on this project? > > As nobody answered if and how I could participate in this project, I > just can make a suggestion to e.g. write an Akai and / or Gigasampler > import module, as I haven't seen that anyone's working on it yet. > > But due to my impatience and demand to be able to use my Gig and Akai > library again (unfortunately I already sold my Akai sampler *sigh*) I > already considered starting to write a usable sample engine on my own in > case this project can be considered as dead. > > How about you Mitchell? > > Regards, > Christian Christian, Impatience is cool. It makes things happen. There hasn't been much going on here. I'm just a user, not a developer, but GigaStudio is my main sample player and I'd love to move my libraries over to Linux one day. so... 1) If someone wrote a gig file reader, I'd test my 100+ libraries and make sure they worked. 2) There is very limited some code out there for this project. I do not know what it does, but if you accomplished #1, I'd help see if we could load them into #2. Anyway, it's a quiet reflector right now, but I' love to see it wake up. Cheers, Mark |
|
From: Steve H. <S.W...@ec...> - 2003-03-17 17:03:41
|
On Thu, Mar 13, 2003 at 06:44:55 -0800, Mark Knecht wrote: > Christian, > Impatience is cool. It makes things happen. > > There hasn't been much going on here. I'm just a user, not a developer, > but GigaStudio is my main sample player and I'd love to move my libraries > over to Linux one day. so... > > 1) If someone wrote a gig file reader, I'd test my 100+ libraries and make > sure they worked. > > 2) There is very limited some code out there for this project. I do not know > what it does, but if you accomplished #1, I'd help see if we could load them > into #2. I've had a minor epiphany(sp?) having breifly used some subset of the swami/fluidsynth combo I'd say we are stupid to go it out own way, we should integrate with the existing stuff as far as possible. Using the swami UI made me realise just how much work has to go into it and it appears (from a cursory glance) to be basicly generic, rather than soundfont specific as I thought. - Steve |
|
From: Mark K. <mar...@at...> - 2003-03-18 00:49:14
|
On Mon, 2003-03-17 at 09:02, Steve Harris wrote: > > I've had a minor epiphany(sp?) having breifly used some subset of the > swami/fluidsynth combo I'd say we are stupid to go it out own way, we > should integrate with the existing stuff as far as possible. > > Using the swami UI made me realise just how much work has to go into it > and it appears (from a cursory glance) to be basicly generic, rather than > soundfont specific as I thought. > > - Steve Steve, Hi. You've been a bit more quiet. Good to see you. At the risk of creating some sort of mega-app, I generally agree. There's no need to create everything new. A Sampler could leverage the work Josh has done and reuse a lot of that interface. It could even integrate into Swami where as Swami becomes the front-end for any number of soft synth apps... Cheers, Mark |
|
From: Josh G. <jg...@us...> - 2003-03-18 08:50:01
|
On Mon, 2003-03-17 at 09:02, Steve Harris wrote: > > I've had a minor epiphany(sp?) having breifly used some subset of the > swami/fluidsynth combo I'd say we are stupid to go it out own way, we > should integrate with the existing stuff as far as possible. > > Using the swami UI made me realise just how much work has to go into it > and it appears (from a cursory glance) to be basicly generic, rather than > soundfont specific as I thought. > > - Steve > My thoughts as well :) Of course I'm a little biased in the whole thing, as Swami has been a hobby of mine for almost 4 years now (if including the Smurf SoundFont Editor). In that time I've re-written the API probably somewhere in between 2.5 to 3 times. I am starting to feel like the underlying architecture is quite good now and am looking forward to implementing more functionality on top of it. Keep in mind that I am speaking of the swami-1-0 CVS branch which has not yet been released (as in packaged, hasn't quite come together yet). I really think Swami could use some more developers, so if anyone is interested, please contact me or join the Swami mailing list. I now feel it appropriate to divulge in a more in depth description of the architecture here, forgive me if it seems lengthy or overwhelming. Although I am quite proud of this project, please try not to take my enthusiasm as overly bragging :) Swami is based on 2 support libraries libInstPatch and libswami with the GUI currently being built on top of these (although a good portion of it may turn into a library as well). These libraries use glib/GObject extensively (for those who aren't familiar with GObject its an object oriented library for C, it provides an extendable type system, inheritable classed objects with signals and properties). This means that the underlying libraries and the functionality they bring do not rely on GUI related libs (X, GTK, etc). The GUI uses GTK2 and is also very object oriented (well, its getting there). I chose this architecture because I wanted the underlying libraries to use C which I feel is the least common multiple when it comes to programming languages, and therefore would increase the scope of use, but also wanted the benefit of an object oriented system. There are also C++ bindings for GTK2 (which I'm sure includes GObject, although I have not researched this). libInstPatch - Instrument patch library --------------------------------------- The library that interfaces to patch files. SoundFont files are currently supported and DLS2/gig are just now being added. Patch files are loaded/saved from a child/parent tree structure of objects which can be easily manipulated using the GObject properties mechanism. The current focus is the object system, there is a little work that needs to be done to make the file parsers usable for those who don't want to use the runtime objects (say if just scanning a patch file for some specific info). This library also transparently manages sample data sources (file, RAM, ROM, swap file, etc) and different bit widths (some work will need to be done for bit width conversion). libswami - Everything else not directly part of the GUI or patch files --------------------------------------- - Maintains a master patch tree utilizing signals for change notification - GObject type based plugin system (GStreamer inspired) - XML save/restore state interface (also GStreamer inspired) - Wavetable and MIDI objects - event queues - Undo/Redo state history (tree based so no loss of actions will occur after an undo/do something else), also utilizes action dependency so arbitrary items can be undone (provided they don't depend on later actions). The GUI uses a master event queue (the same events that are logged to the state history) to track patch object changes and will update itself on regular intervals (necessary since GTK is not multi-threaded). This also means that changing an object property will cause any other GUI views to also be updated. Whats ahead (lots of things to do) --------------------------------------- Python support - pygtk has some nice scripts to generate python interfaces for GObject code. Using this, much of the API is generated, only some functions need to be manually written. With python I can see a powerful web based instrument database being created. Also a GUI embedded shell for doing complex editing tasks or creating scripts. Flexible object oriented GUI and session load/save state (utilizing XML). Much of this is already underway. Generic control interface (using GValue, a container for different data types, int, float, string, etc). This will be used for MIDI controls, instrument effects, any object property, and all other things that can be thought of as a control. The GUI will utilize this for flexible control layouts, etc. Currently in the works. Flexible canvas widget. Move sample waveform display (loop setting) to use canvas so effects (envelopes, LFOs etc) can be overlayed on top. Also allow any generic control to be controlled on a canvas. A segment based waveform modeller (also canvas based). Use lines, curves and freeform segments to create sample waveforms with loop support. A nice side effect is multiple samples can be created at different tones with high precision. Instrument patch conversion GUI hooks for DLS2/gig files Additional patch formats (Virtual banks, Akai, GUS, etc) Auto sample tuning with fftw (plugin already written, no GUI yet) Free compression standard created for patch files using FLAC (a simple proof of concept SoundFont compressor has already been written, I'd like to extend the format to include other patch formats like DLS2). I feel like the architecture is ready for all these features. Just needs to be coded :) If you are still reading this, are you interested? I keep feeling like there really isn't that much left for all this to be realized, but sometimes it seems like its taking so long too. If I get some expressed interest in helping with development, I'll be quick to update the API docs on the site, post directions for checking out the swami-1-0 branch, todo stuff, etc. Cheers. Josh Green |
|
From: Steve H. <S.W...@ec...> - 2003-03-18 09:14:01
|
On Tue, Mar 18, 2003 at 12:49:30AM -0800, Josh Green wrote: > I now feel it appropriate to divulge in a more in depth description of > the architecture here, forgive me if it seems lengthy or overwhelming. > Although I am quite proud of this project, please try not to take my > enthusiasm as overly bragging :) Thanks. That was helpful. Givent that one of the main goals of linuxsampler was to have disk streamed sample playback, how much effort is required to add this, and would it fit with the currect architecture - I guess it would go into fluid? - Steve |
|
From: Josh G. <jg...@us...> - 2003-03-18 11:25:54
|
On Tue, 2003-03-18 at 01:12, Steve Harris wrote: > On Tue, Mar 18, 2003 at 12:49:30AM -0800, Josh Green wrote: > > I now feel it appropriate to divulge in a more in depth description of > > the architecture here, forgive me if it seems lengthy or overwhelming. > > Although I am quite proud of this project, please try not to take my > > enthusiasm as overly bragging :) > > Thanks. That was helpful. > > Givent that one of the main goals of linuxsampler was to have disk > streamed sample playback, how much effort is required to add this, and > would it fit with the currect architecture - I guess it would go into fluid? > > - Steve > I have suggested streamed sample playback on the FluidSynth list a few times. It sounds like it is on the todo list for next major release (who knows when that will be). The main reason I wanted it was for being able to use the same audio device, without conflict, for doing things like previewing samples off disk and the like. The current view of some of the FluidSynth developers is that it isn't really necessary. I almost tend to agree, since memory is quite cheap these days and when someone talks about several gig patch files, I think they are usually referring to a collection of many instruments rather than a single instrument (how long does one want those samples to be, holding a key down for more than a minute would seem absurd ~10mb CD quality audio). Okay, I'm sure there are those grand piano patches with every single key sampled.. At any rate, I'm sure it probably wouldn't be that hard to add this type of support. I'm no expert on FluidSynth internals though. It would fit in fine with the Swami architecture though, as the wavetable object is fairly abstract in how a wavetable device handles itself. From what I currently know of FluidSynth goals, it currently falls short of the linuxsampler goal of multi patch format support. FluidSynth is likely to remain SoundFont based, but its sfloader API that I use to interface Swami's instruments to it is generic enough to allow any format to be synthesized (within the constraints of SoundFont synthesis). Of note is that DLS2 would seem to fit fairly well into the SoundFont model (seems to be a rip off in some respects), although I do think that DLS2 is much more extendable than SoundFont 2. Things like self compiling code and that kind of stuff (that was being discussed previously), may also be out of the scope of what is planned (CCing FluidSynth list so they can correct me if I'm wrong). I do feel that FluidSynth is quite an excellent synthesizer though, and is fairly complete in its support of SoundFont 2. The modulator support is something of great beauty :) The FluidSynth developers have done a nice job of making it more optimized as well, although I'm sure there is always room for more. Cheers. Josh |
|
From: Josh G. <jg...@us...> - 2003-03-13 18:54:21
|
On Thu, 2003-03-13 at 04:56, Christian Schoenebeck wrote: > Sorry guys for being impatient, but is there any progress at all or are > you all too busy to work on this project? > > As nobody answered if and how I could participate in this project, I > just can make a suggestion to e.g. write an Akai and / or Gigasampler > import module, as I haven't seen that anyone's working on it yet. > I'm working on it right now actually with libinstpatch. I've already written the DLS runtime objects and RIFF parser and DLS loader. All of it is untested and it will be a little while before these files are actually editable in Swami as there are many other things that need to be done with the Swami 1.0 branch before it is usable (lots and lots of new features being added). If you would like to see this code for some reason, its in the swami-1-0 branch in Swami CVS (http://swami.sourceforge.net), expect brokenness. > But due to my impatience and demand to be able to use my Gig and Akai > library again (unfortunately I already sold my Akai sampler *sigh*) I > already considered starting to write a usable sample engine on my own in > case this project can be considered as dead. > > How about you Mitchell? > > Regards, > Christian > Cheers. Josh Green |
|
From: Mitchell <mgjohn@u.washington.edu> - 2003-03-13 18:57:55
|
Actually I have been experiencing similar frustrations. Also, I don't really like the framework of the current distribution of linuxsampler, since I would rather work in C (just a personal preference), and also I don't understand where they want to go with the code so I haven't contributed anything or don't realy know how. I am on the very edge of writing my own sampler framework, so maybe we could start our own homebrew and then later see what could be incorporated back into linuxsampler. Otherwise, if someone would explain to me where and how I could contribute, I could work on linuxsampler and contribute some code. However, from reading the source that's there so far it seems like most of the organization is still in peoples' heads :) -Mitchell You can talk to me on IRC too... I'm mitchell on #lad on freenode.net and on #foo on irc.silverninja.net. On Thu, Mar 13, 2003 at 01:56:29PM +0100, Christian Schoenebeck wrote: > Sorry guys for being impatient, but is there any progress at all or are > you all too busy to work on this project? > > As nobody answered if and how I could participate in this project, I > just can make a suggestion to e.g. write an Akai and / or Gigasampler > import module, as I haven't seen that anyone's working on it yet. > > But due to my impatience and demand to be able to use my Gig and Akai > library again (unfortunately I already sold my Akai sampler *sigh*) I > already considered starting to write a usable sample engine on my own in > case this project can be considered as dead. > > How about you Mitchell? > > Regards, > Christian > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Mark K. <mk...@co...> - 2003-03-13 19:40:10
|
> Actually I have been experiencing similar frustrations. Also, I > don't really like the framework of the current distribution of > linuxsampler, since I would rather work in C (just a personal > preference), and also I don't understand where they want to go with > the code so I haven't contributed anything or don't realy know how. > > I am on the very edge of writing my own sampler framework, so maybe > we could start our own homebrew and then later see what could be > incorporated back into linuxsampler. > > Otherwise, if someone would explain to me where and how I could > contribute, I could work on linuxsampler and contribute some code. > However, from reading the source that's there so far it seems like > most of the organization is still in peoples' heads :) > > -Mitchell Mitchell, et. all, Making the presumption that I even know what the 'preferred' interface for Linux Sample might be (which I don't) there are other sample player motif's that could be of big value in my studio. One would be something like Native Instrument's Battery, which is more specifically for playing one shot samples vs. loops based samples, and gets used for drums a lot. There was a newer app that popped up on the radar recently called hydrogen, which is a Linux based drum pattern editor. If that was combined with something Battery like, then we'd have a cool combination for making noise in the neighborhood. Anyway, I'd encourage you to take you energy and get going on something you want to do. There are people waiting out here, like me, who just want to make music. Good luck, Mark |
|
From: Christian S. <chr...@ep...> - 2003-03-14 20:46:31
|
On Thu, 13 Mar 2003 10:57:27 -0800 Mitchell <mgjohn@u.washington.edu> wrote: > Actually I have been experiencing similar frustrations. Also, I > don't really like the framework of the current distribution of > linuxsampler, since I would rather work in C (just a personal > preference), Why? Is it just because you're more used to C? Personally I think the OO way is cleaner and easier to read than having thousands of functions with cryptic names and data structures, especially as we will have a lot of data structures and functions working on them with actually simillar tasks. That's just predestined for inheritance. But I would not insist on it, at least if it will help to bring some progress. > and also I don't understand where they want to go with > the code so I haven't contributed anything or don't realy know how. I guess you already browsed the CVS repository (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linuxsampler/). If you want to be able to check in you have to register of course first to sf.net and Benno, Steve or Juan must then add you to the developers of the project. > I am on the very edge of writing my own sampler framework, so maybe > we could start our own homebrew and then later see what could be > incorporated back into linuxsampler. My thoughts, though I'm still hoping someone will reply. Regards, Christian |
|
From: Christian S. <chr...@ep...> - 2003-03-14 20:46:19
|
On 13 Mar 2003 10:55:02 -0800 Josh Green <jg...@us...> wrote: > On Thu, 2003-03-13 at 04:56, Christian Schoenebeck wrote: > > > > As nobody answered if and how I could participate in this project, I > > just can make a suggestion to e.g. write an Akai and / or > > Gigasampler import module, as I haven't seen that anyone's working > > on it yet. > > > > I'm working on it right now actually with libinstpatch. I've already > written the DLS runtime objects and RIFF parser and DLS loader. All of Oh, I remember you mentioned the Gig format would be based on DLS, are you sure it is and if yes where did you get your information? Have you found some specs? And what about the Akai formats? > new features being added). If you would like to see this code for some > reason, its in the swami-1-0 branch in Swami CVS Hmmm... I could not locate anything DLS related, but maybe I did not look thoroughly enough. Have you already checked it in? Regards, Christian |
|
From: Josh G. <jg...@us...> - 2003-03-15 08:08:51
|
There's a plug that readers might find interesting for the release of Swami 0.9.1 at the end of this email, if someone gets tired of reading it :) On Fri, 2003-03-14 at 12:46, Christian Schoenebeck wrote: > On 13 Mar 2003 10:55:02 -0800 > Josh Green <jg...@us...> wrote: > > > > I'm working on it right now actually with libinstpatch. I've already > > written the DLS runtime objects and RIFF parser and DLS loader. All of > > Oh, I remember you mentioned the Gig format would be based on DLS, are > you sure it is and if yes where did you get your information? Have you > found some specs? And what about the Akai formats? > Well, actually it was someone else that mentioned it was based on DLS2. When I look at a gig file in a hex editor, it does indeed identify itself as such. There is a lot of flexibility with DLS2 files, including conditional chunks, so I'm not sure if anything custom is added for .gig files or not. I'll find out pretty soon though, once I start actually testing the new DLS code. In regards to the Akai formats.. This is currently secondary on my list. There is still a bit of work that needs to be done in the area of generalizing Swami in the area of patch formats. Up until recently much of the code was still SoundFont centric. DLS2 will be the first additional format to be added. After this it should be easier to add additional formats to the libInstPatch/Swami API, with the result being an editable patch format that can be software synthesized (within the constraints of SoundFont synthesis in the case of using FluidSynth as the synthesizer). > > new features being added). If you would like to see this code for some > > reason, its in the swami-1-0 branch in Swami CVS > > Hmmm... I could not locate anything DLS related, but maybe I did not > look thoroughly enough. Have you already checked it in? > Yes it is checked in, just not in the main CVS "head" branch. If you are browsing CVS online with viewcvs, you'll want to select the "swami-1-0" branch in the selector at the bottom of the page. Here is the command you should use to checkout the swami-1-0 branch: cvs -z3 -d:pserver:ano...@cv...:/cvsroot/swami checkout -r swami-1-0 swami The only addition being "-r swami-1-0" from a regular checkout command. The swami-1-0 branch is quite different from the current "head" branch. libInstPatch is entirely GObject based, the GUI requires GTK2, and lots of other stuff. Like I mentioned before, its also not quite usable yet (too many new things, not quite integrated yet). > Regards, > Christian > If you have any interest in helping with Swami please let me know. I'm looking for developers. The learning curve might be a bit steep with the glib/GObject/GTK2 architecture, but the code documentation is pretty thorough and I'm willing to help fill in the gaps for someone who was dedicated to the task :) Cheers. Josh Green P.S. I just released Swami 0.9.1 to coincide with the recent FluidSynth 1.0.0 release. FluidSynth is much improved to the last iiwusynth version (its old name). JACK is now usable with Swami as well (FluidSynth does the real work). I use it myself with an Edirol PCR-50 USB keyboard which comes with lots of MIDI controls for modulating effects in real time. I hacked in a global modulators feature into Swami for this purpose, so a set of real time effect controls can be defined for all instruments. Swami: http://swami.sourceforge.net FluidSynth: http://www.fluidsynth.org |
|
From: Steve H. <S.W...@ec...> - 2003-03-18 09:09:30
|
On Mon, Mar 17, 2003 at 04:49:05PM -0800, Mark Knecht wrote: > On Mon, 2003-03-17 at 09:02, Steve Harris wrote: > > > > I've had a minor epiphany(sp?) having breifly used some subset of the > > swami/fluidsynth combo I'd say we are stupid to go it out own way, we > > should integrate with the existing stuff as far as possible. > > > > Using the swami UI made me realise just how much work has to go into it > > and it appears (from a cursory glance) to be basicly generic, rather than > > soundfont specific as I thought. > > > > - Steve > > Steve, > Hi. You've been a bit more quiet. Good to see you. Yes, I'm worried that the linuxsampler is one more thing than I can handle. I have a bunch of minor projects on the go that all require coding, and I find more inspirational than a sampler. I'm happy to supply DSP code and so on ofcourse, but I dont think I can contribute to the bulk of the coding. Especially if its in C++. But, yeah. All the developers on htis list should try swami before discussing development any further. - Steve |
|
From: Mark K. <mar...@at...> - 2003-03-18 13:00:18
|
On Tue, 2003-03-18 at 01:08, Steve Harris wrote: > > But, yeah. All the developers on htis list should try swami before > discussing development any further. > > - Steve I agree. Josh has done a lot, and even if they chose not to do this, there is a lot to learn from his work. |
|
From: Peter H. <pe...@ha...> - 2003-03-18 23:11:58
|
Josh Green wrote: > On Tue, 2003-03-18 at 01:12, Steve Harris wrote: > >>Givent that one of the main goals of linuxsampler was to have disk >>streamed sample playback, how much effort is required to add this, and >>would it fit with the currect architecture - I guess it would go into fluid? >> >>- Steve >> > > > I have suggested streamed sample playback on the FluidSynth list a few > times. It sounds like it is on the todo list for next major release (who > knows when that will be). <chop> > The current view of some of > the FluidSynth developers is that it isn't really necessary. Streamed sample playback is on my todo list for quite a while now. However, the first goal was to develop a synthesizer that is MIDI and SoundFont compatible. Version 1.0 pretty much satisfies that goal. As soon as we split of the development branch (version 1.1.x) we can start adding sample streaming. Maybe the better thing to do is to improve the current sfloader and sample API and add the intelligence of the sample streaming (i.e. caching, preloading) in libInstPatch rather than in FluidSynth. >>From what I currently know of FluidSynth goals, it currently falls short > of the linuxsampler goal of multi patch format support. FluidSynth is > likely to remain SoundFont based, but its sfloader API that I use to > interface Swami's instruments to it is generic enough to allow any > format to be synthesized (within the constraints of SoundFont > synthesis). I'm of the opinion that it's better that FluidSynth implements the SoundFont synthesis model as efficiently as possible instead of trying to become a swiss army knife for wavetable synthesis. I think the users benefit more from having the choice between several small but optimized synthesizers rather than one big, buggy synthesizer. As you said, additional patch types can be supported through libInstPatch, if they map reasonably well to the SoundFont synthesis model. Peter > Josh > |
|
From: Josh G. <jg...@us...> - 2003-03-19 00:38:09
|
On Tue, 2003-03-18 at 15:16, Peter Hanappe wrote:
>
> Streamed sample playback is on my todo list for quite a while now.
> However, the first goal was to develop a synthesizer that is MIDI
> and SoundFont compatible. Version 1.0 pretty much satisfies that goal.
> As soon as we split of the development branch (version 1.1.x) we can
> start adding sample streaming.
>
Thanks for clarifying that.
> Maybe the better thing to do is to improve the current
> sfloader and sample API and add the intelligence of the sample
> streaming (i.e. caching, preloading) in libInstPatch rather than in
> FluidSynth.
>
It would seem like something that could be implemented with the sfloader
sample API with some callback functions. As far as Swami, I think the
streaming functionality would be part of the libswami FluidSynth plugin
rather than libInstPatch, whose scope is currently patch file specific.
Sample streaming functionality is not likely to be something very
re-usable at any rate.
Preloading is probably possible now using the preset notify function
that you just added. So when a preset first gets selected (bank:program
change) the application (in this case Swami) could preload a chunk of
all samples of that preset. The only thing I think missing is a way to
stream the actual sample data from the app to FluidSynth. I guess there
are probably a couple ways to go about this though, both using callback
methods to fetch the audio?
If it was a continous audio stream then it would be up to the app to do
its own looping and would have to continously feed audio through a
callback (even for small looped samples), although perhaps the callback
could return with a code to stop audio for say the end of a single shot
sample. Prototype (naming convention probably wrong):
/**
* @sample: Sample structure allocated by app
* @size: Number of samples requested
* @buffer: Buffer to store the samples
*
* Returns: Number of samples transferred to buffer. Any size less than
* @size will cause the stream to stop.
*/
typedef int (*FluidSFLoaderStreamContinous)(iiwu_sample_t *sample,
guint size, fluid_float_t *buffer);
The other method would be that FluidSynth would manage the sample and
looping parameters and would pass a sample position along with the
number of samples to the callback function when fetching audio.
typedef void (*FluidSFLoaderStreamSample)(iiwu_sample_t *sample,
guint offset, guint size, fluid_float_t *buffer);
Does that make any sense? Perhaps both methods should be implemented? As
far as sample caching. Is it necessary to implement one's own caching
mechanism (rather than rely on the OS?) I'm sure the answer to this is
probably yes.
>
> >>From what I currently know of FluidSynth goals, it currently falls short
> > of the linuxsampler goal of multi patch format support. FluidSynth is
> > likely to remain SoundFont based, but its sfloader API that I use to
> > interface Swami's instruments to it is generic enough to allow any
> > format to be synthesized (within the constraints of SoundFont
> > synthesis).
>
> I'm of the opinion that it's better that FluidSynth implements the
> SoundFont synthesis model as efficiently as possible instead of trying
> to become a swiss army knife for wavetable synthesis. I think the users
> benefit more from having the choice between several small but optimized
> synthesizers rather than one big, buggy synthesizer. As you said,
> additional patch types can be supported through libInstPatch, if they
> map reasonably well to the SoundFont synthesis model.
>
> Peter
>
Sounds good to me :) Cheers.
Josh
|
×
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