Menu
▾
▴
linuxsampler-devel
|
From: Marek P. <ma...@na...> - 2003-06-29 10:42:36
|
Hi guys, i'd like to talk about the future development of the linux version of libakai. My feeling is that the lib could be extended to include other formats aswell. For that we'd need to have: 1. easier way to add new formats 2. an API thoughts? Marek |
|
From: Josh G. <jg...@us...> - 2003-06-29 13:31:49
|
On Sun, 2003-06-29 at 15:03, Marek Peteraj wrote: > Hi guys, > > > i'd like to talk about the future development of the linux version of > libakai. My feeling is that the lib could be extended to include other > formats aswell. For that we'd need to have: > > 1. easier way to add new formats > 2. an API > > > thoughts? > > Marek > I'm sure you've already read some of my emails about libInstPatch. Have you checked out this library yet? Its goals are the same as what you described and it already has an API and easy way to add new formats (just derive new types from base patch objects). Josh Green libInstPatch API docs: http://swami.sourceforge.net/devel.php |
|
From: Marek P. <ma...@na...> - 2003-06-29 15:04:57
|
On Sun, 2003-06-29 at 15:30, Josh Green wrote: > On Sun, 2003-06-29 at 15:03, Marek Peteraj wrote: > > Hi guys, > > > > > > i'd like to talk about the future development of the linux version of > > libakai. My feeling is that the lib could be extended to include other > > formats aswell. For that we'd need to have: > > > > 1. easier way to add new formats > > 2. an API > > > > > > thoughts? > > > > Marek > > > > I'm sure you've already read some of my emails about libInstPatch. Have > you checked out this library yet? Its goals are the same as what you > described and it already has an API and easy way to add new formats > (just derive new types from base patch objects). Hi Josh, Yeah i know, but i've got a few concerns regarding libinstpatch, first of all i'd like to refer to some of your previous mails: <snip> <1> Of course it might make sense to use this library directly instead of implementing it in libInstPatch, depending on how flexible its API is. Then again it might be more convenient if the code was part of libInstPatch. <2> ...because I'm thinking that filesystem and lowlevel device access code really does not belong in libInstPatch. It seems somewhat like a portability nightmare and I wan't to try and keep libInstPatch as portable as possible. <snip> The thing is that there's a majority of diskbased formats out there (at least those we need, there's halion and exs24 format as well) http://www.pleasewipeyourfeet.com/webtest/linuxsampler/samplerformat.html Second thing is that libinstpatch is really C, while C++ is more desirable for this project(i'm not really C++ myself right now, but there's lots of people here who are C++, there's Benno, Juan, Christian, Marc, and there's a few more lad members in lurk mode all of which are c++ afaik :) Third thing is that it might be more desirable to design an API/lib around formats which are most widely used and popular in the pro audio world, such as akaiS1000/3000, Gig. Finally i'd like to say that i'd rather see this project go the "from scratch" way for everything(format lib, engine, GUI), although it might seem that it's just reinventing the wheel again. Marek |
|
From: Josh G. <jg...@us...> - 2003-06-29 17:07:27
|
On Sun, 2003-06-29 at 19:25, Marek Peteraj wrote: > Hi Josh, > > Yeah i know, but i've got a few concerns regarding libinstpatch, first > of all i'd like to refer to some of your previous mails: > > <snip> > <1> > > Of course it might make sense to use this > library directly instead of implementing it in libInstPatch, depending > on how flexible its API is. Then again it might be more convenient if > the code was part of libInstPatch. > > <2> > ...because I'm thinking that filesystem and lowlevel device > access code really does not belong in libInstPatch. It seems somewhat > like a portability nightmare and I wan't to try and keep libInstPatch as > portable as possible. > > <snip> > I seemed to recall writing emails later, retracting some of those statements. I'm actually not opposed to writing that sort of code into libInstPatch, but I'd prefer to try and use file images rather than accessing low level hardware. > The thing is that there's a majority of diskbased formats out there > (at least those we need, there's halion and exs24 format as well) > > http://www.pleasewipeyourfeet.com/webtest/linuxsampler/samplerformat.html > > Second thing is that libinstpatch is really C, while C++ is more > desirable for this project(i'm not really C++ myself right now, but > there's lots of people here who are C++, there's Benno, Juan, Christian, > Marc, and there's a few more lad members in lurk mode all of which are > c++ afaik :) > Nothing stopping libInstPatch++. > Third thing is that it might be more desirable to design an API/lib > around formats which are most widely used and popular in the pro audio > world, such as akaiS1000/3000, Gig. > libInstPatch isn't designed around any particular format. Thats the nice thing about it. I don't think you want to design any instrument library around a particular format if its going to support multiple formats. I think some formats make more sense to write import loaders for rather than full on object manipulation/save support, though. > Finally i'd like to say that i'd rather see this project go the "from > scratch" way for everything(format lib, engine, GUI), I'd rather see linuxsampler go the way of interoperability, so that other projects can easily integrate and co-operate with linuxsampler. What you a describing might then become something of a collection of programs working together, which is the way I see Linux audio going. Creating one large project is just too un-manageable in my opinion, I think the goals of Swami are almost too much to manage. > although it might > seem that it's just reinventing the wheel again. > Yes, it does. But thats how the open source world works at times so go ahead. I'll be working on Swami/libInstPatch, which I would love to see work with linuxsampler in the future. And yes, I think I would be a little disappointed if another project was started with similar goals, but thats unfortunately also how the open source/free software world goes. I think there is quite a lot of man hours put into the API design of libInstPatch though, hell I re-wrote it like 3 times now. > > Marek Cheers. Josh Green |
|
From: Marek P. <ma...@na...> - 2003-06-30 12:16:59
|
Hi Josh, > I'm actually not opposed to writing that sort<diskbased formats> of code into > libInstPatch, but I'd prefer to try and use file images rather than > accessing low level hardware. AFAIK it makes no difference under linux, you can open a /dev/hd- or a /dev/scdx just like a file. > > > The thing is that there's a majority of diskbased formats out there > > (at least those we need, there's halion and exs24 format as well) > > > > http://www.pleasewipeyourfeet.com/webtest/linuxsampler/samplerformat.html > > > > Second thing is that libinstpatch is really C, while C++ is more > > desirable for this project(i'm not really C++ myself right now, but > > there's lots of people here who are C++, there's Benno, Juan, Christian, > > Marc, and there's a few more lad members in lurk mode all of which are > > c++ afaik :) > > > > Nothing stopping libInstPatch++. But instead of rewriting it as C++, woudln't it be better to write a new one in collaboration with others here(Christian, Paul, Marc, me ...) and design it with respect to other popular formats? The main benefit would be the experience other people have with them. > > Finally i'd like to say that i'd rather see this project go the "from > > scratch" way for everything(format lib, engine, GUI), > > I'd rather see linuxsampler go the way of interoperability, so that > other projects can easily integrate and co-operate with linuxsampler. JACK :) > Creating one large project is just too un-manageable in my opinion, Have a look at ardour, which can be seen as a monster project in the linux audio domain. Marek |
|
From: Josh G. <jg...@us...> - 2003-06-30 13:06:56
|
On Mon, 2003-06-30 at 16:37, Marek Peteraj wrote: > Hi Josh, > > AFAIK it makes no difference under linux, you can open a /dev/hd- or a > /dev/scdx just like a file. > Sure, but not portable and some strange formats might require low level hardware control. Once again I'm not opposed to this. > > > > > The thing is that there's a majority of diskbased formats out there > > > (at least those we need, there's halion and exs24 format as well) > > > > > > http://www.pleasewipeyourfeet.com/webtest/linuxsampler/samplerformat.html > > > > > > Second thing is that libinstpatch is really C, while C++ is more > > > desirable for this project(i'm not really C++ myself right now, but > > > there's lots of people here who are C++, there's Benno, Juan, Christian, > > > Marc, and there's a few more lad members in lurk mode all of which are > > > c++ afaik :) > > > > > > > Nothing stopping libInstPatch++. > > But instead of rewriting it as C++, woudln't it be better to write a new > one in collaboration with others here(Christian, Paul, Marc, me ...) and > design it with respect to other popular formats? The main benefit would > be the experience other people have with them. > > No no.. Not re-writing it, having a binding for it. This is what a lot of the GObject based C libraries have that are related to GTK+ and such. Thats the plus I think with C, its the least common denominator. > > > Finally i'd like to say that i'd rather see this project go the "from > > > scratch" way for everything(format lib, engine, GUI), > > > > I'd rather see linuxsampler go the way of interoperability, so that > > other projects can easily integrate and co-operate with linuxsampler. > > JACK :) > Of course. But I also like the abstraction that FluidSynth has, although SoundFont 2 centric, you can load arbitrary patch formats as long as they somewhat conform to the SF2 model. > > Creating one large project is just too un-manageable in my opinion, > > Have a look at ardour, which can be seen as a monster project in the > linux audio domain. > Sure, and I've used it. Its still got lots of problems and doesn't have MIDI support yet. Not to say that it isn't a good thing. Its just, good things take time. > Marek I realize that there is no reason for me to push libInstPatch/Swami stuff here if no one wants it, I'd rather be doing some actual work. The reality of it is though, this is work that is already existing and I am someone who has a lot of time on his hands and am willing to help. You seem to be voicing stuff as if its the voice of linuxsampler, but I would like to hear opinions from others of this project. What linuxsampler I think needs most right now is cooperation and activity. Go extend libakai if you want, I know that my time would be more efficiently used by working on libInstPatch. Once you have something, we can all decide what makes the most sense for inclusion in linuxsampler. I think for now I am done with this discussion though and would like to return to coding. Cheers. Josh Green |
|
From: Marek P. <ma...@na...> - 2003-06-30 13:48:48
|
> I realize that there is no reason for me to push libInstPatch/Swami > stuff here if no one wants it, I'd rather be doing some actual work. The > reality of it is though, this is work that is already existing and I am > someone who has a lot of time on his hands and am willing to help. > You seem to be voicing stuff as if its the voice of linuxsampler, I'm not. I'm just throwing in my ideas. > but I would like to hear opinions from others of this project. Me too. > What linuxsampler I think needs most right now is cooperation and > activity. That was exactly my point(a new lib). Marek |
|
From: Josh G. <jg...@us...> - 2003-06-30 14:29:02
|
On Mon, 2003-06-30 at 18:09, Marek Peteraj wrote: > > What linuxsampler I think needs most right now is cooperation and > > activity. > > That was exactly my point(a new lib). > I don't think activity necessarily means re-writing instrument libraries for which there already exists code for. Maybe collecting some synthesis code together would be more productive? Brainstorming about the various synthesis elements in different instrument patch formats and how to program these and link them together when it comes to actually synthesizing them. From my point of view, the instrument loading/saving library (whatever it happens to become) should have its objects separate from what the synthesizer is actively working on. This is because in an editing environment the patch objects will be accessed from GUI elements and other things that are inherently slow and not as real time critical as the synthesis output. So other thoughts about what process occurs to get the relevent parameters from the patch objects to the synthesis elements, etc. Anyways, just blabbing, and I did kind of want that previous email thread to end, so... Josh |
|
From: Christian S. <chr...@ep...> - 2003-06-30 14:37:33
|
Es geschah am Montag, 30. Juni 2003 15:05 als Josh Green schrieb: > On Mon, 2003-06-30 at 16:37, Marek Peteraj wrote: > > Hi Josh, Hi everybody! > > AFAIK it makes no difference under linux, you can open a /dev/hd- or a > > /dev/scdx just like a file. > > Sure, but not portable and some strange formats might require low level > hardware control. Once again I'm not opposed to this. I don't see your problem with the low level hw acess josh. That's just a matter of encapsulation. Define a stream class, put the low level code in there and let the rest of the lib just use the methods of this stream class. At the moment the whole thing will be used under Linux only anyway and if some day somebody want to use it under OSwhatever just add the low level code into your stream class. You could even decide one day to completely drop the low level approach at all for POSIX systems and do a simple f = fopen(/dev/cdrom); That way, no matter what you do, it won't affect the code of your lib at all except the few lines in your stream class. > > But instead of rewriting it as C++, woudln't it be better to write a new > > one in collaboration with others here(Christian, Paul, Marc, me ...) and > > design it with respect to other popular formats? The main benefit would > > be the experience other people have with them. > > No no.. Not re-writing it, having a binding for it. This is what a lot > of the GObject based C libraries have that are related to GTK+ and such. > Thats the plus I think with C, its the least common denominator. Maybe that's the best for the moment to leave libinstpatch as is and just writing a C++ frontend. But I will never understand why people still stick with C... > > JACK :) > > Of course. But I also like the abstraction that FluidSynth has, although > SoundFont 2 centric, you can load arbitrary patch formats as long as > they somewhat conform to the SF2 model. And that's the problem. > I realize that there is no reason for me to push libInstPatch/Swami > stuff here if no one wants it, I'd rather be doing some actual work. libinstpatch with a C++ frontend sounds good and should IMO be used in LinuxSampler, but I think it would be better to write a GUI from scratch. I would propose an observer model encapsulating the logic of the gui (e.g. network connection to LinuxSampler host, sample editing) and then using simple plugins for the actual visual part, so you can choose between gtk, qt,... > What linuxsampler I think needs most right now is cooperation and > activity. Go extend libakai if you want, I know that my time would be > more efficiently used by working on libInstPatch. Once you have > something, we can all decide what makes the most sense for inclusion in > linuxsampler. No one talked about extending libakai. That's the least problem, because these couple of lines can easyily incorpareted anywhere. I just thought a general API for the various formats would be nice, but without your support Josh it doesn't make sense, so just using your C++ bindings for libinstpatch might be the best. Best regards, Christian |
|
From: Josh G. <jg...@us...> - 2003-07-01 15:23:59
|
On Mon, 2003-06-30 at 16:33, Christian Schoenebeck wrote: > > > > Sure, but not portable and some strange formats might require low level > > hardware control. Once again I'm not opposed to this. <-- ***** #### > > I don't see your problem with the low level hw acess josh. I wrote "Once again I'm not opposed to this", which I thought would have conveyed that I don't have a problem with it. > Maybe that's the best for the moment to leave libinstpatch as is and just > writing a C++ frontend. > > But I will never understand why people still stick with C... Understandable. I had thought of C++ at the time when I was trying to decide what to re-write Swami with. As to how good my decision was with using GObject, that remains to be seen. Essentially I wanted to try to program something that could be used by everyone, and so C seemed the most logical choice. I like the relation that GTK+/GObject/glib has, although I didn't really compare that with C++ toolkits. I don't think GTKmm for GTK2 was anywhere near where it is now, so thats why I choose GObject. If I had more knowledge of C++ and what can and can't be done, perhaps I would have chosen otherwise, but for now I think to start re-writing everything in C++ would be a mistake. Perhaps I may undertake this in the future, but things are already object oriented, so I just have to live with some of the excess C object fluff, and hope that if I do recode it in C++ it won't be too much of an architecture change. > > > JACK :) > > > > Of course. But I also like the abstraction that FluidSynth has, although > > SoundFont 2 centric, you can load arbitrary patch formats as long as > > they somewhat conform to the SF2 model. > > And that's the problem. >From the view of linuxsampler, yes, for FluidSynth, not a problem, but a design decision. Many patch formats do fit well within the SoundFont model, at least DLS2 and other simple formats like GUS. I'm not completely familiar with gigasampler yet, but from what I've seen probably a good portion of its synthesis model could fit into SoundFont as well. > > I realize that there is no reason for me to push libInstPatch/Swami > > stuff here if no one wants it, I'd rather be doing some actual work. > > libinstpatch with a C++ frontend sounds good and should IMO be used in > LinuxSampler, but I think it would be better to write a GUI from scratch. I > would propose an observer model encapsulating the logic of the gui (e.g. > network connection to LinuxSampler host, sample editing) and then using > simple plugins for the actual visual part, so you can choose between gtk, > qt,... Swami is becoming pluggable in regards to the GUI. I don't want to go into it too much yet, since its not at a stage where one can actually use it. Getting very very close though. Never underestimate how long things can take, is what I try and remind myself of. > No one talked about extending libakai. That's the least problem, because these > couple of lines can easyily incorpareted anywhere. I just thought a general > API for the various formats would be nice, but without your support Josh it > doesn't make sense, so just using your C++ bindings for libinstpatch might be > the best. > I've been thinking about this a bit more. For right now I'm going to keep concentrating on Swami/libInstPatch development. This is the best use of my time, I think. Once the new development code is usuable as a program then I'd feel more comfortable returning to the subject as to whether linuxsampler should make use of it or not. I definitely think Swami has many similar goals as linuxsampler, mainly in creating a generic instrument patch editing and composition environment. I have no intentions of doing synthesis though, and thought that was going to be linuxsampler's main focus. That is why I saw it as potentially 2 projects that could work happily together. It may end up being that my choice of using C was a bad one in regards to interfacing with other people and projects, but I still haven't come to this conclusion yet. BTW I did look into Gtkmm to try and get an idea of what a C++ binding would entail. The process of creating a binding for GObjects for C++ looks similar to the procedure for Python bindings, even uses some of the same tools. So perhaps it may be quite easy to create a C++ binding. > > Best regards, > Christian > Cheers. Josh |
Thanks for helping keep SourceForge clean.
X