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

[Linuxsampler-devel] GUI screenshot , Linuxsampler status,thoughts etc (long)

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

I started to write the GUI for the module editor for Linuxsampler.
See this screenshot for now (code will follow later).

http://www.linuxdj.com/benno/lsgui4.gif

About 1.5 day of coding. (Qt lib) ;)

You can create modules with an arbitrary number of input and output ports that
 can be of several kind of types (midi, audio, control ports etc).
You can connect ports that are of the same type and move the modules around
the screen.
As you can see in the screenshot the idea is to make a very general purpose
system which is not tied to MIDI.
The screenshot shows that the MIDI keymap module acts as a proxy between
the MIDI data and the sampler module itself which knows nothing about MIDI etc.

More details about the GUI within the next days ... meanwhile if you have
suggestions to make (GUI wise) speak out loudly ;-)

here follows a response to Josh's mail:

Scrive Josh Green <jg...@us...>:
> 
> If Linuxsampler can be thought of as a network of synthesis modules then
> couldn't it be possible to have an API for creating a synthesis model
> for a particular instrument format? So say for a SoundFont one would do
> something like (sudo code follows):
> 
(....)
> 
> etc.. I am still of the opinion that the instrument patch objects should
> be decoupled from the synthesis engine, due to its real time nature. So
> a handler for a particular instrument format would then setup the
> synthesis model (perhaps the network would be compiled or optimized in
> some way). 
(....)
> I'm not sure how efficient this would be in practice but it does fit the
> modular goal. The nice thing about this is that other projects could
> take direct advantage of Linuxsampler (such as Swami).
> 
> 

Yes the goal is to design it that way, thus it will be easy to build a powerful
SF2 engine too..
Regarding swami / libinstpatch etc: please work together with Christian S. on
the DLS / GIG loading stuff since he is interested too. As said LinuxSampler
needs some lib that decodes the chunks and presents them in a way that is easy
to handle for the engine.
The less dependencies it has the easier it is to use the lib within linuxsampler.

cheers,
Benno



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

Re: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

[Marek P. <ma...@na...>]

> 
> Some of the developers (Marek ? ;-) ) do not like Qt that much (because it is
> C++ based or because Qt is GPL and not LGPL like gtk)

Personally i have nothing against Qt being GPL or C++ or whatever, in
fact Qt is cool, but i simply like GTK+ better that's all. :)

Marek

Re: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

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

On Sun, 2003-07-20 at 18:29, Benno Senoner wrote:
> Josh is writing LibInstPatch and I think it is a nice lib but I'm unsure if
> it is the right way to go.

Just wanted to clear up one point that Benno mentioned. I'm curious if
anyone has actually looked at libInstPatch (not the one with swami-0.9.x
thats totally outdated, but the one in the swami-1-0 development branch,
use "co -r swami-1-0 swami" when checking out CVS, explains more on
Swami download page). I really think it is a nice library architecture
and it is constantly improving. It already does quite a bit of what you
have been talking about:

IpatchRiffParser - RIFF parser object
Patch formats are loaded into multi-threaded safe object trees
"named" object properties for easy setting of object values
All file IO done via IpatchFile which is a virtual file object
Abstract sample storage (RAM, file, swap, libsndfile, etc)
Supports DLS and SoundFont files currently, rather trivial to add
additional formats.
Has a nice GUI already, although incomplete (Swami)

Anyways, I'm not sure what the goal is of the LinuxSampler project, but
I know I'll be continuing work on my own project. If there is some way
in which my work could help the goals of LinuxSampler, I think it would
be cool. I don't really feel like I have gotten any feedback on if
libInstPatch makes sense or not for this project, so until I do, I will
keep pushing it :) Cheers.
	Josh Green

Re: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

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

On Mon, 2003-07-28 at 16:32, Alexandre Prokoudine wrote:

> Ahem, doesn't Google rule? :-)
> 
> http://www.midi.org/about-midi/dls/dls2spec.shtml

Yes it does, almost as much as the MMA sucks. You can happily download
DLS1 in electronic form, unfortunately DLS2 is by order only and they
give you a nice printed copy which is much harder to transport on laptop
(my copy is in California, while I'm currently in Germany). DLS1 has
much in common with DLS2 though. Cheers.
	Josh Green

Re: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

[Alexandre P. <av...@al...>]

Josh Green wrote
> On Sun, 2003-07-27 at 00:59, Christian Schoenebeck wrote:
> >   
> >  oI
> > IO  Yep, count me in!
> > 
> > I hope to see one of you guys in IRC (#lad) today (sunday), so you (perhaps 
> > Marek?) can tell me what's already done and what we'll still have to do. I 
> > have e.g. no DLS specs yet, so would be nice if somebody could send it to me.
> > 
> > CU
> > Christian
> 
> I'm on #lad right now, since I'm also interested in doing GIG support
> with Swami. The DLS loader is already working in libInstPatch, but I'd
> like to add the gig extensions. Its somewhat unfortunate that one can
> not tell the difference between a .gig and .dls file until running into
> one of the .gig specific chunks. They kind of polluted the magic file
> name space :) I have DLS specs, unfortunately they are a printed copy.
> If someone has an electronic form, I'd also be interested. Cheers.
> 	Josh Green

Ahem, doesn't Google rule? :-)

http://www.midi.org/about-midi/dls/dls2spec.shtml

-- 
Alexandre Prokoudine
ALT Linux Documentation Team
JabberID: av...@al...

Re: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

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

On Sun, 2003-07-27 at 00:59, Christian Schoenebeck wrote:
>   
>  oI
> IO  Yep, count me in!
> 
> I hope to see one of you guys in IRC (#lad) today (sunday), so you (perhaps 
> Marek?) can tell me what's already done and what we'll still have to do. I 
> have e.g. no DLS specs yet, so would be nice if somebody could send it to me.
> 
> CU
> Christian

I'm on #lad right now, since I'm also interested in doing GIG support
with Swami. The DLS loader is already working in libInstPatch, but I'd
like to add the gig extensions. Its somewhat unfortunate that one can
not tell the difference between a .gig and .dls file until running into
one of the .gig specific chunks. They kind of polluted the magic file
name space :) I have DLS specs, unfortunately they are a printed copy.
If someone has an electronic form, I'd also be interested. Cheers.
	Josh Green

Re: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

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

Es geschah am Sonntag, 20. Juli 2003 18:29 als Benno Senoner schrieb:
> While I would technically able to do such stuff I'd rather prefer to focus
> on building an efficient low level engine so it would be handy if some of
> you could implement the GIG importing lib.
> Any volounteers ?
  
 oI
IO  Yep, count me in!

I hope to see one of you guys in IRC (#lad) today (sunday), so you (perhaps 
Marek?) can tell me what's already done and what we'll still have to do. I 
have e.g. no DLS specs yet, so would be nice if somebody could send it to me.

CU
Christian

Re: [Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

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

I've also been thinking more about Swami/libInstPatch and Linuxsampler.
I realized that there really is no reason for me to push
Swami/libInstPatch for the Linuxsampler project, in fact when I started
to think of the modular nature that Linuxsampler aims to be it occured
to me that it shouldn't matter.

If Linuxsampler can be thought of as a network of synthesis modules then
couldn't it be possible to have an API for creating a synthesis model
for a particular instrument format? So say for a SoundFont one would do
something like (sudo code follows):

/* streams and interpolates audio data, loop and tuning parameters */
add_wave_table ("Wavetable")

add_lowpass_filter ("Filter")
add_envelope ("VolumeEnv")
add_envelope ("ModEnv")
add_lfo ("ModLFO")
add_lfo ("VibratoLFO")
add_pan ("Panning")

etc.. I am still of the opinion that the instrument patch objects should
be decoupled from the synthesis engine, due to its real time nature. So
a handler for a particular instrument format would then setup the
synthesis model (perhaps the network would be compiled or optimized in
some way). A note on handler would then be written which might look
like:

voice = new_synthesis_voice ("SoundFont")
voice.Wavetable.set_sample_callback (my_sample_callback)
voice.Wavetable.set_pitch (midi_note)
voice.Filter.set_Q (soundfont Q)
..

I'm not sure how efficient this would be in practice but it does fit the
modular goal. The nice thing about this is that other projects could
take direct advantage of Linuxsampler (such as Swami).


If anyone cares to check out whats currently happening with the
development version of Swami I put up a screenshot.

http://swami.sourceforge.net/images/swami_devel_screenshot.jpg

You'll notice a few gigasampler files open as well as one DLS file and a
SoundFont. Only sample info and splits are viewable with DLS2 files at
the moment, and there is still quite a lot of work to do before I would
consider it a working instrument editor, but things are progressing
quite nicely now :) Of note is that the piano, splits and sample view
are now implemented with the GnomeCanvas (of additional note is that
GnomeCanvas 2.x is not dependent on Gnome). This means piano and splits
can be scaled and controls can be overlayed onto the same canvas. If you
would like to try out the development version, let me know. This stuff
is so new it hasn't been checked into CVS yet. Cheers.
	Josh Green

[Linuxsampler-devel] Linuxsampler status,thoughts etc (long)

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

Hello,
sorry for being that quiet during the last weeks, work overload you know ..
Anyway during the last days a few of us (me, Marek, Juan L. and others)
discussed about the possible roadmaps for linuxsampler.

While we haven't produced useful code lately, some of us came up with
nice ideas. Some say linuxsampler will never happen, or that
some do "voice" too much, but hey I think passionate discussion sparks interest
and creativity. Plus good things take time to develops and unfortunately
 we are not in the fortunate situation like Paul D. where we can
work full time on our favorite OSS project.

That said, personally I'm still convinced that it should become a "modular
sampler" because I do not like hardcoded engines that much since they limit the
creativity of the user.
Obviously should allow importing multiple sampleformats but in this regard
there is a opinion split: some (like me) say we should write separate
sample loading modules for each format (gig, akai etc) that store the samples in
datastructures using the native representation, while others say that it
would be better to create some powerful (and if possible extensible) internal
format that can accomodate most common formats in order to simplify things.

I'm not sure about that and if we really write a modular sampler
(where you can assemble the various engines using a GUI editor along the
lines of NI Reaktor) if in case of using "native sampleformat loaders" the
 code duplication would really be that high as some state (Marek).

Of course it would be cool to use the GIG engine to play AKAI samples
and viceversa. But when using native loaders you could alway write a
GIG to AKAI converter module that reads the GIG metadata that the GIG loader
 put into mem and converts them to the AKAI datastuctures.
Of course the "universal internal format" has the advantage that
you can convert form any input format to any output format by writing
 a converter module that can convert from/to the universal to/from the
 specific format.
That way if you have N formats you only need to write N converter modules
instead of N*(N-1) if you are using only native formats.

I back the native format loader solution since you can tune the engine
 exactly to work hand in hand with that format instead of going through
the intermediate universal format.

This mean you can tune the GIG engine to work exactly with GIG specific
enveloping data, filters, looping etc. Same applies to all other formats.

Of course one would want to use the GIG engine to play AKAI samples but we can
write a converter module (that is probably quite simple since AKAI's sample
 engine is simpler than GIG's one).
But I think the N*(N-1) n. of converter modules equation does not apply here
since I think it is unlikely to want to play GIGs using the limited AKAI engine.
Since we include both engines it makes sense to use the native one.
So probably the number of format converter modules is more likely determined
by (N of simple formats) *( N of complex formats).
Since the N of complex formats (like GIG) is not that high I guess the number
of converter modules would still stay quite low but with the benefits of
having native loaders and native engines that go hand in hand.

Marek would object here but I think using an internal universal format
make it hard to avoid conversion losses that makes it hard to achieve
faithful playback.
Of course many sampleformats share many properties like keymaps,
envelopes, filters, looping information etc, but unfortunately often each
format uses its own representation where a bijective A<->B converter function
 does not exist.

For example when speaking about envelopes: some formats use simple ADSR models
 while others allow arbitrary linear or exponential enveloping segments.

How to avoid the code duplication in the loaders and engines ?
Use the modular approach !
Since the final engines will be compiled using the following approach:
module editor -> C source code -> compiled .so file that gets loaded by the sampler
the speed will be OK even if we assemble the engines using a Reaktor-like GUI
(and it will be very userfriendly and handy to add new custom engines).

So basically when we have implemented enough basic building blocks (filters,
envelope generators, etc) designing new engines becomes a breeze.


Not sure about the loaders (if we could use a GUI editor to compose loaders too).
Most sampling formats are based on the RIFF format (GIG, DLS, SF2, WAV etc)
so a RIFF parser is needed anyway but the individual modules that interpret
the data contained in various RIFF chunks still need be written by hand.
But to achieve maximum flexibility instead of writing a monolithic format
 importer we could write let's say a general RIFF parser and then specialized
 modules that interpret the various RIFF chunks.
That way if we happen to support formats that share some characterisics
(eg GIG is nothing more than DLS with some proprietary additions) can can
fully reuse the modules.

I think using the approaches described above the "code duplication" can
be kept really low while the flexibility increases quite.

Regarding the GUIs: As you know I support the idea of totally decoupling
 the engine from the GUI. It improves code quality because you do not
mix GUI stuff with engine stuff. Plus if you use a TCP socket you can
even run the GUI on a remote machine that can run even another OS than
Linux. (eg. assume a Mac OS X frontend box networked with a headless
linuxsampler box).

As for the module composer form the discussion we had on IRC we seem to agree
that the best thing to do would be making a "stupid" GUI which only forward
commands to the engine.
That way when you wire togheter the basic building blocks in the GUI editor
apart from displaying them wired together it does nothing than issuing
a connect(module1.out,module2.in) command to the engine which does the
appropriate stuff.

That way you can even use scripts, commandlines or textual interfaces
that can manage and construct audio rendering engines.

Regarding the sample importing modules: I think it would be wise to use a bottom
up approach thus IMHO it would be better to not use and extend complex
monolithic applications that can read/edit samples.

Josh is writing LibInstPatch and I think it is a nice lib but I'm unsure if
it is the right way to go.
I think the only way we can solve the problems that linuxsampler poses is a
divide et impera approach. So write many "micro modules" and "wire" them toghether
 using a GUI.
That way you can, as Steve Harris said some time ago, make a good "sampler
construction kit".

Regarding the code and what to implement first.
I admit we haven't done much lately but meanwhile the ideas kept flowing and I
think it helps to avoid design errors.

Thanks to Sebastien and Christian we now have libakai running on Linux.
(libakai is a small lib that reads an parses AKAI sample images).
I think this is the right kind of lib for linuxsampler since it is lean, very
low level, does not contain a GUI and can easily be embedded into linuxsampler
 importing modules.

So basically we need to figure out which kind of modules we should start
implementing.
It is not easy to choose where to start since design errors in one module
can later affect the design of other modules.

So I think it would probably be the best to start with the GUI.
A module editor similar to Reaktor where you can assemble basic building blocks.
The real DSP network building process will occur within the sampler engine
so the GUI will remain quite simple and stupid.

I think once the GUI runs we can start to implement the necessary backend.
The logic that manages DSP modules networks and then at a later stage
the code that turns the DSP network in a C file that can be compiled into
a .so file that runs the actual DSP stuff.

I'm using Qt and will post a few screenshots for commenting in a few weeks.
At least we will have some code and stuff to play with.
The Qt Designer has the nice capability to allow the integration of custom
 made Widgets which can be used to build more complex ones.
That way you can for example make audio in, audio out, midi in,midi out, CV in,
CV out widget which you can use to make new basic building blocks.

Some of the developers (Marek ? ;-) ) do not like Qt that much (because it is
C++ based or because it Qt si GPL and not LGPL like gtk) but that is not a
problem. GUIs can be implemented by using any toolkit (even curses etc) since the
 engine it totally decoupled from the GUI.
Personally I like Qt very much because I think GUIs can be implemented easier
 in an object oriented language rather than in C plus Qt classes are IMHO
 much cleaner (and easier to use) than Gtk/gtkmm ones.
It is just a personal taste so if at a later stage someone wants to implement
a gtk based GUI feel free to do so. The engine just does not care what kind
 of GUI drives it.

Returning to the sample importer modules: as said before it would be nice
to support the AKAI (via libakai) and GIG formats.
GIG is a bit more tricky since we need to decode the GIG specific chunks.
Ruben Van Royen has done some good stuff some ago (Paul K. and Marek do have
 Rubens header files) but it is still not complete.
So one task that it open to some of you developers (the ones that do have
gigasampler) is to continue that stuff (contact Paul K. or Marek for more infos).
So it would be cool if you could produce a small and lean
libgig that does something like libakai does: parse and read GIG files, decode
the various chunks (envelope data, filters, looping data, MIDI keymaps) etc.
While it is not a really hard task, it is not very easy either.
You need a running gigasampler, some sample libraries. Decode data, change
parameters, see what changes in the data chunks on the GIG file etc.
Not to mention that you need a copy of the DLS2 specs (since GIG is based on
DLS2) which are not publicy available on the net. (but some on the list like
Paul K seem to have a copy so just ask him how to obtain one).

While I would technically able to do such stuff I'd rather prefer to focus on
building an efficient low level engine so it would be handy if some of you could
 implement the GIG importing lib.
Any volounteers ?
Such a lib would not only benefit linuxsampler but other OSS projects too.
(sample editors, softsamplers etc).

Ok shutting up now ;-)
I'd like you guys to comment on the various issues (if my reasoning is flawed,
what you would do in different ways etc).

cheers,
Benno
http://linuxsampler.sourceforge.net



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

Re: [Linuxsampler-devel] libakai what's next

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

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

Re: [Linuxsampler-devel] libakai what's next

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

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

Re: [Linuxsampler-devel] libakai what's next

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

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

Re: [Linuxsampler-devel] libakai what's next

[Marek P. <ma...@na...>]

> 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

Re: [Linuxsampler-devel] libakai what's next

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

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

Re: [Linuxsampler-devel] libakai what's next

[Marek P. <ma...@na...>]

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

Re: [Linuxsampler-devel] libakai what's next

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

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

Re: [Linuxsampler-devel] libakai what's next

[Marek P. <ma...@na...>]

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

Re: [Linuxsampler-devel] libakai what's next

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

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

[Linuxsampler-devel] libakai what's next

[Marek P. <ma...@na...>]

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

Re: [Linuxsampler-devel] Re: i'm interested

[Steve M. <sm...@so...>]

> Perhaps libsamplerate (http://www.mega-nerd.com/SRC/index.html) might
> be something similar to what you mentioned. I just recently heard
> about it, so I'm not real familiar with its capabilities. Cheers.

thanks, josh.  i had come across that quite some time ago (a fairly
memorable logo :^) ), but had since lost track of it.

browsing the api, it performs the following conversions on float sample
data, with conversion ratio represented by a double:

enum
      {
          SRC_SINC_BEST_QUALITY       = 0,
          SRC_SINC_MEDIUM_QUALITY     = 1,
          SRC_SINC_FASTEST            = 2,
          SRC_ZERO_ORDER_HOLD         = 3,
          SRC_LINEAR                  = 4
      } ;

where "SINC" is the "Julius O. Smith" method
( http://www-ccrma.stanford.edu/~jos/resample/ ).

it's designed to process data in streams..  so, this library would
probably work well for the 'standard' scaling methods.  and it's GPL.

steve

Re: [Linuxsampler-devel] Re: i'm interested

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

On Tue, 2003-06-24 at 00:40, Steve Mokris wrote:
> > The term often used is interpolation. There are different methods for
> > this that trade off between quality and speed. Linear interpolation is
> > probably the simplest (besides no interpolation :) There is cubic
> > interpolation and other more complex ones as well, each increases the
> > number of points used in approximating (interpolating) samples.
> 
> to throw something else out there into the possible-feature-pool (and
> supporting the general opensource premise that "everything is better than
> something"), i think i might be interesting/useful to have a conveniently
> abstracted interface for converting "input wave + note data" into "output
> wave"; that is, pitch scaling.
> 
> ...and also be able to select which algorithm is used, as a parameter
> intrinsic to each instrument.  that way, one might (eventually) implement
> all of the above-mentioned algorithms, plus some others such as
> formant-preserving pitch scaling, time-preserving pitch scaling, and
> maybe, for retro effect, emulations of a few of those aggressively clunky
> samplers from the 1980s.
> 
> steve
> 

Perhaps libsamplerate (http://www.mega-nerd.com/SRC/index.html) might be
something similar to what you mentioned. I just recently heard about it,
so I'm not real familiar with its capabilities. Cheers.
	Josh Green

[Linuxsampler-devel] Re: i'm interested

[Steve M. <sm...@so...>]

> The term often used is interpolation. There are different methods for
> this that trade off between quality and speed. Linear interpolation is
> probably the simplest (besides no interpolation :) There is cubic
> interpolation and other more complex ones as well, each increases the
> number of points used in approximating (interpolating) samples.

to throw something else out there into the possible-feature-pool (and
supporting the general opensource premise that "everything is better than
something"), i think i might be interesting/useful to have a conveniently
abstracted interface for converting "input wave + note data" into "output
wave"; that is, pitch scaling.

...and also be able to select which algorithm is used, as a parameter
intrinsic to each instrument.  that way, one might (eventually) implement
all of the above-mentioned algorithms, plus some others such as
formant-preserving pitch scaling, time-preserving pitch scaling, and
maybe, for retro effect, emulations of a few of those aggressively clunky
samplers from the 1980s.

steve

Re: [Linuxsampler-devel] i'm interested

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

On Fri, 2003-06-20 at 20:44, np9...@dd... wrote:
> Hi!

Hello.

> I've been planning to write a software sampler for Linux, perhaps I
> could join your team? I have a few questions though:
> How do you make pitch scaling?

The term often used is interpolation. There are different methods for
this that trade off between quality and speed. Linear interpolation is
probably the simplest (besides no interpolation :) There is cubic
interpolation and other more complex ones as well, each increases the
number of points used in approximating (interpolating) samples.

> How good/fast is your pitch scaling technique?

linuxsampler is currently in somewhat planning stage still, there is
some base code from the evo project though. If you want to check out a
synth that is already working (although with a more limited scope,
SoundFont 2 files only), FluidSynth is a cool project
(http://www.fluidsynth.org). My own project, Swami
(http://swami.sourceforge.net) acts as a front end for this synth, and
may be a front end for linuxsampler in the future.

> What do you have that Ardour doesn't?
> 

As far as I know Ardour is mainly a multi track audio recorder with
support for things like LADSPA plugins and routing of audio via JACK. A
software synth, such as what linuxsampler aims to be, is in a different
category all together, but would work hand in hand with ardour (the
output of the synth could be routed via JACK to ardour for processing).

> Cheers,
> Tom Weber
> 

Cheers.
	Josh Green

[Linuxsampler-devel] i'm interested

[<np9...@dd...>]

Hi!
I've been planning to write a software sampler for Linux, perhaps I
could join your team? I have a few questions though:
How do you make pitch scaling?
How good/fast is your pitch scaling technique?
What do you have that Ardour doesn't?

Cheers,
Tom Weber

Re: [Linuxsampler-devel] new site for beta testing

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

On Wed, 2003-06-18 at 11:34, Alexandre Prokoudine wrote:
> On 17 Jun 2003 20:57:33 +0200
> Josh Green <jg...@us...> wrote:
> 
> > already supports loading DLS2. Also re-writing many of the widgets
> > (piano, key/velocity splits, sample viewer) to use the GnomeCanvas
> 
> Do you use GtkWaveForm widget?

I've looked at it a bit before. My requirement is that it uses
GnomeCanvas, since my other controls will also be using this and I would
like to have the option of overlaying them on the same canvas.
GtkWaveForm doesn't appear to be GnomeCanvas based. There are also a
number of custom things I need to do with it, like having loop point
markers and a loop cross point display I have in mind. I was thinking of
using GtkWaveForm and Ardour as examples though (Ardour uses the
GnomeCanvas, or rather GtkCanvas which is essentially the same API).
Cheers.
	Josh Green