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

Patent drivel, was: Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

[Robert J. <rob...@da...>]

Hi,

>
> Can we get back to linuxsampler technicals ?
>

I'm happy that you (as I) live in Europe where software patents are illegal. 
Though this will probably change...which is quite a failure.

I'm also happy that you have solid prior art for the sample loading technique.

But I think also think (as Mark mentioned) that you will just have to get used 
to people asking about how LS is affected by the patent. 
By now it's common knowledge that there exist patents in this area, so I would 
be surprised if people didn't ask.
Putting a FAQ on the site with some info might help.

As to the merits of the patent in question, I too agree that the patent is 
absurd and should never have been granted...but this happens all the time I'm 
afraid...

About the enforcability of the patent... I've heard numerous stories about the 
way the system works (both here in EU and in the US) and the truth is that it 
doesn't really matter whether you are right, unless you have _lots_ of cash 
to back up your claim.

Luckily we have the FSF that are willing to help in this situation, hopefully 
that would be enough.

---
Just look at the recent circus of SCO vs the World for a glimpse at how 
incredibly F***ed the world of lawyers and suits is.

There was a recent thread on music-dsp about patents in the audio arena that 
was very interesting.

---
Okay, enough ranting...
Keep up the coding, lets not worry about things that are beyond the 
comprehension of the average man :)

/Robert

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

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

 > 
> Not only that, but I recorded the same drone using GSt and LS into Pro
> Tools and then looked visually at the two. With GSt set at full volume
> the two looked basically identical in Pro Tools down at the sample
> level.

Well, a sampler (when playing a sample at the root note) it's just copying
the data from the source (the sample stored in RAM/disk) to the output,
aka the soundcard. And since your audio paths are all digital it's
easy to get matching samples down to bit level (as long both samplers
only copy the data and do not screw it up by filters, interpolators etc).
As for interpolation, currently we use only linear interpolation,
cubic interpolation is implemented but commented out because it needs
 some tweaking for the stereo samples. We will make it configurable.

> > 
> > IIRC you played LS with --fragmentsize 256, lower this to 64
> > it should give you a latency of 2*64 = 128 frames = 3msec
> > 
> > Please redo the test and tell us if the latency is correct
> > (probably you need to add the 1.1msec of MIDI Note-on latency if you
> trigger
> > LS via external MIDI device).
> 
> I will revisit this tomorrow when I have more time. I think my tests
> need some corrections for sure. In LS I was using the 256 fragment size.
> In GSt I was using a buffer size of 128. That will certainly account (I
> think) for some of the reason that LS looked slower.

Be sure to pay attention what 128 stands for.
128 bytes or frames (samples, regardless if stereo or mono) or 
samples (128 samples played in stereo means 64 frames thus half of the
buffer time than if the 128 samples were played in mono).
I think the easiest ist to increase the buffer values in both samplers
to let's say 2048 or more and look at the delay time which will be easier
to analyze than the dimes you get when you use very short buffers.

> 
> As for how I measured it, I set up both GSt and LS to be triggered by my
> keyboard. The keyboard came into Linux on a MidiSport 2x2 input, and
> then using kaconnect was routed to a MidiSport output to go out to GSt,
> and routed directly to LS in software.

Well to be fair you must then subtract 1.1msec from the GSt latency
because in the above case GSt is treated unfairly (data gets into the
linux box and virtually immediately to LS but takes an additional
1.1msec (midi wire speed of a 3byte note-on/off message) to get out to GSt.

> 
> The LS output was then routed through playback_1/2 to the ADAT2-1/2
> outputs and was recorded by Pro Tools.
> 
> In the GSt box MIDI goes in through an AP2496 MIDI port and triggers
> GSt, which goes out over ADAT, into the HDSP 9652 where it is routed in
> hardware to ADAT2-3/4 outputs where it is recorded by Pro Tools at the
> same time as LS.

Just make sure that the tests are fair and that none of both apps
gets penalized by additional audio buffering (due to routing) etc.

> 
> All I was looking at was the relative positions of the two stereo
> signals in Pro Tools and seeing an offset with LS coming later.
> 
> I need to redo this with at least the same buffer size for the two
> samplers.

I'm very curious about the results .... :-)

> 
> 
> One other interesting thing I did was to just brutally overload LS with
> polyphony while using the drone library.Since you don't handle the
> sustain pedal yet I simply laid my arms down on the keyboard covering
> all the white notes for about 4 octaves and held them. All indications
> were that all the notes played. Since this library's note length is
> scaled by the keyboard position, the high notes cut out first, and then
> lower and lower notes cut out as they run their length. Since you don't
> loop yet, I can hear the notes drop out one by one. Everything seemed
> correct.

The only performance problems I could see is when one tries to play
a sample at let's say +4 octaves (48 semitones) up from the root note.
This means you play the sample 16 times faster ( 2^(48/12)=16 ) and
the initial RAM buffer time goes down from 1.5 to 0.1 sec which is too
short to compensate for disk latency. The associated 
streaming ringbuffer will run into problems too because the disk will
have hard time to keep up with ensuring that it is always filled.
But other streaming samplers have the same problem too and in practice
it will rarely happen because modern streaming sampling libraries are
heavily multisamples and the pitch shifting will be max a few semitones
so one has not to worry about that.

> 
> This was quite good.
> 
> One small negative I found was during just simple playing, upon release
> of a note I get definite little 'clicks' out of LS. I am guessing that
> this is probably because you implement no ADSR yet? I'm sure that GSt
> implements some standard release envelope to eliminate that problem. It
> probably continues to play the voice for a few more samples as it ramps
> the volume down to zero. If this is the case, then it's not a problem
> and you just need to work on providing something like that when you can.

Yes envelopes are not implemented yet thus when you release a key the
sample is cut off abruptly which leads to this high frequency click.
Full enveloping will come soon to but before implementing it we will
make sure that LS is able to handle sample accurate events so that
it can more easily be part of future integrated enviroments like
eg. Cubase and Halion. (where Halion can render sample accurate events
based of Cubase's sequencer events which are sent through the VSTi API).

> 
> For technical reasons I couldn't get the Bardstown piano over to the
> Linux box yet. It's compressed in an executable file. Is there some way
> to run that in Linux, maybe using a DOS window or something? I've never
> used dosemu or any form of DOS under Linux, so I don't know how to
> proceed. 
> 
> I can probably copy the library to a 1394 drive and then mount it under
> Linux. If there's no easier way to do it, then I will work on doing it
> that way tomorrow.

It's probably easier to decompress it on a Windows box and transfer it
to Linux.

> 
> I want to work on this as it will start to demonstrate LS's ability to
> work with multi-velocity libraries.

Some libraries already trigger the right samples associated to velocity-splits
some still show funny sample mapping but according to Christian after
his corrections all these problems will go away in one rush.

> 
> Overall I'm very happy and MOST impressed by the two signal outputs
> looking sample for sample identical in Pro Tools. That quite an
> accomplishment considering (I think) that no one has looked at this
> before me. Congrats to all of you!

Congrats to you for the in-depth tests, probably LS would (after getting
 to production quality state) not be the same without your feedback !
You are part of the of the team too, right ? So change that sentence
into "congrats to us all" :-)

I'm already drooling when we will be able to impress the northernsounds folks
 with a fully working version, screenshots and mp3 demos recorded using LS.
Having followed their passionate discussions I guess it will ignite a quite
 heavy discussion :-)
Meanwhile let's work hard to get to that point.

cheers,
Benno
http://www.linuxsampler.org
 


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

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

On Tue, 2003-10-28 at 16:52, be...@ga... wrote:

> > 1) The first issue is that the Mellotron voice I'm playing is 10 seconds
> > long on GSt, at which point I hear it loop and start over. (Hit one key
> > and hold it for 30 seconds and you hear 3 passes.) However, LSt is only
> > playing the voice for 2 seconds and then quitting. It doesn't loop the
> > voice after 10 seconds, it just stops.
> 
> Keep in mind that looping is not implemented yes.

Yep, this turned out to be an aspect of that specific library. I loaded
up some really long gig files from a library called 'Drone Archeology'.
They can run over a minute long and they played correctly in LS. 

Not only that, but I recorded the same drone using GSt and LS into Pro
Tools and then looked visually at the two. With GSt set at full volume
the two looked basically identical in Pro Tools down at the sample
level.

> If LS is playing only for 2secs then it is playing a sample that is only.
> 2secs long. The wrong pitch is because LS is not honoring all the articulation
> parameters yet. Christian will at that soon.

Great.

> >
> > 3) Zooming way in while in Pro Tools shows the latency of LSt to be
> > slower than GSt. It doesn't look horrible, and I didn't try to measure
> > the difference as I don't have much time right now. We can focus on that
> > later.
> 
> Hmm this is interesting. How do you measure the latency ?
> Can you record both the time a midi event gets in and put that on the
> same time scale as the audio in PT ?
> 
> IIRC you played LS with --fragmentsize 256, lower this to 64
> it should give you a latency of 2*64 = 128 frames = 3msec
> 
> Please redo the test and tell us if the latency is correct
> (probably you need to add the 1.1msec of MIDI Note-on latency if you trigger
> LS via external MIDI device).

I will revisit this tomorrow when I have more time. I think my tests
need some corrections for sure. In LS I was using the 256 fragment size.
In GSt I was using a buffer size of 128. That will certainly account (I
think) for some of the reason that LS looked slower.

As for how I measured it, I set up both GSt and LS to be triggered by my
keyboard. The keyboard came into Linux on a MidiSport 2x2 input, and
then using kaconnect was routed to a MidiSport output to go out to GSt,
and routed directly to LS in software.

The LS output was then routed through playback_1/2 to the ADAT2-1/2
outputs and was recorded by Pro Tools.

In the GSt box MIDI goes in through an AP2496 MIDI port and triggers
GSt, which goes out over ADAT, into the HDSP 9652 where it is routed in
hardware to ADAT2-3/4 outputs where it is recorded by Pro Tools at the
same time as LS.

All I was looking at was the relative positions of the two stereo
signals in Pro Tools and seeing an offset with LS coming later.

I need to redo this with at least the same buffer size for the two
samplers.


One other interesting thing I did was to just brutally overload LS with
polyphony while using the drone library.Since you don't handle the
sustain pedal yet I simply laid my arms down on the keyboard covering
all the white notes for about 4 octaves and held them. All indications
were that all the notes played. Since this library's note length is
scaled by the keyboard position, the high notes cut out first, and then
lower and lower notes cut out as they run their length. Since you don't
loop yet, I can hear the notes drop out one by one. Everything seemed
correct.

This was quite good.

One small negative I found was during just simple playing, upon release
of a note I get definite little 'clicks' out of LS. I am guessing that
this is probably because you implement no ADSR yet? I'm sure that GSt
implements some standard release envelope to eliminate that problem. It
probably continues to play the voice for a few more samples as it ramps
the volume down to zero. If this is the case, then it's not a problem
and you just need to work on providing something like that when you can.

For technical reasons I couldn't get the Bardstown piano over to the
Linux box yet. It's compressed in an executable file. Is there some way
to run that in Linux, maybe using a DOS window or something? I've never
used dosemu or any form of DOS under Linux, so I don't know how to
proceed. 

I can probably copy the library to a 1394 drive and then mount it under
Linux. If there's no easier way to do it, then I will work on doing it
that way tomorrow.

I want to work on this as it will start to demonstrate LS's ability to
work with multi-velocity libraries.

Overall I'm very happy and MOST impressed by the two signal outputs
looking sample for sample identical in Pro Tools. That quite an
accomplishment considering (I think) that no one has looked at this
before me. Congrats to all of you!

Cheers,
Mark

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

crive Mark Knecht <mar...@co...>:

>
> Benno,
>    OK, I came home for lunch since I was curious about trying this out.
> I am getting sound from LinuxSampler, so congrats. That's great!
>
>    I only have one GSt library on this machine right now, which is the
> 'String Boxes' library from Sonic Implants. I have loaded the 8 voice
> Mellotron Choir gig file. I am listening to both GSt and LSt them side
> by side. I am able to get both single notes and polyphony from LSt.
> That's good. Some data:
>
> 1) The first issue is that the Mellotron voice I'm playing is 10 seconds
> long on GSt, at which point I hear it loop and start over. (Hit one key
> and hold it for 30 seconds and you hear 3 passes.) However, LSt is only
> playing the voice for 2 seconds and then quitting. It doesn't loop the
> voice after 10 seconds, it just stops.

Keep in mind that looping is not implemented yes.
If LS is playing only for 2secs then it is playing a sample that is only.
2secs long. The wrong pitch is because LS is not honoring all the articulation
parameters yet. Christian will at that soon.
This will correct all errors you encountered.
(wrong sample triggered, thus often it sounds out of tune or the note
scale is completely screwed up).

For example if you try the 100MB church organ from G-Town:
http://62.13.11.115/gtown/

it sounds bad too because the note scale does not sound correctly.


>
> 2) The pitch of the LSt voice doesn't sound quite right. It seems too
> high and brittle. Twice as high, possibly? This is most likely that
> we're not picking up the intended middle C correctly I think. (C3 or C4
> - it changes from file to file I think.)

This is normal for the reason stated above.
Christian hurry up ! :-)
>
> 3) Zooming way in while in Pro Tools shows the latency of LSt to be
> slower than GSt. It doesn't look horrible, and I didn't try to measure
> the difference as I don't have much time right now. We can focus on that
> later.

Hmm this is interesting. How do you measure the latency ?
Can you record both the time a midi event gets in and put that on the
same time scale as the audio in PT ?

IIRC you played LS with --fragmentsize 256, lower this to 64
it should give you a latency of 2*64 = 128 frames = 3msec

Please redo the test and tell us if the latency is correct
(probably you need to add the 1.1msec of MIDI Note-on latency if you trigger
LS via external MIDI device).

>
>    I set up a quick Pro Tools session and recorded them both at the same
> time from the same key hit. The 24-bit zipped file with both sounds
> separate is about 2MB. That is probably too large for me to send to the
> reflector. Shall I send you a copy directly? I'm attaching the shorter,
> 16-bit version here, but at 350K your reflector may bounce it. Do you
> have an ftp site somewhere where I could drop audio like this? Maybe
> even in CVS somewhere?

I could open you an account on the LS.
But I'd like to wait for Christian's comments if it is too early
for such tests. (because he must add articulation otherwise all but the
simple GIGs will play incorrectly).

> Certainly. I didn't take it the least bit personally. Please don't take
> offense in the future when 100's of people coming from years of GSt
> background ask the same questions. Take some time and write a position
> statement on it today, put it on the web site and let's just point
> people towards it. The only thing I can promise you is that I'm not
> going to be the last to ask it!! ;-)

You are completely right.
As long as users are doing us an excellent service like you are doing
 they are allowed to pose this question :-)

PS: your message with attachment probably did not make it through
the mailing list (I'll forward the file to Christian).
In future please keep the test files on your box and we will agree
off-list where to put them.

PS: the current version of LS simply sums up voices and divides the
result by 4:
in audiothread.cpp:
sample_point = this->pAudioSumBuffer[u] / 4; // FIXME division by 4 just for
testing purposes (to give a bit of head room when mixing multiple voices together)

this means your headroom is about 12db (1/4) so don't be surprised if you
hear clipping when lots of voices are playing.

We will make this configurable or some good soul will add a limiter/compressor.
But I think the best solution would (when jackd support will be in) to
simply output the audio in 32bit float and then run it through external
 compressor/limiter/amp plugins.


cheers,
Benno
http://www.linuxsampler.org



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

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

Reposting due to the attachment holding the information you might all
want to read back.

Sorry about that.

Can we work out a standard place to put audio clips? I don't run a web
server or ftp server here.

Thanks,
Mark

On Tue, 2003-10-28 at 12:39, Mark Knecht wrote:
> On Tue, 2003-10-28 at 09:31, be...@ga... wrote:
> 
> > 
> > Keep in mind that here is no concept of midi channel yet, so you can
> > just send midi data (note on/off) to any channel of the ALSA port
> > linuxsampler creates.
> > 
> > Let us know if when getting back home you are able to get out sound
> > of LS. 
> > 
> 
> Benno,
>    OK, I came home for lunch since I was curious about trying this out.
> I am getting sound from LinuxSampler, so congrats. That's great!
> 
>    I only have one GSt library on this machine right now, which is the
> 'String Boxes' library from Sonic Implants. I have loaded the 8 voice
> Mellotron Choir gig file. I am listening to both GSt and LSt them side
> by side. I am able to get both single notes and polyphony from LSt.
> That's good. Some data:
> 
> 1) The first issue is that the Mellotron voice I'm playing is 10 seconds
> long on GSt, at which point I hear it loop and start over. (Hit one key
> and hold it for 30 seconds and you hear 3 passes.) However, LSt is only
> playing the voice for 2 seconds and then quitting. It doesn't loop the
> voice after 10 seconds, it just stops.
> 
> 2) The pitch of the LSt voice doesn't sound quite right. It seems too
> high and brittle. Twice as high, possibly? This is most likely that
> we're not picking up the intended middle C correctly I think. (C3 or C4
> - it changes from file to file I think.)
> 
> 3) Zooming way in while in Pro Tools shows the latency of LSt to be
> slower than GSt. It doesn't look horrible, and I didn't try to measure
> the difference as I don't have much time right now. We can focus on that
> later. 
> 
>    I set up a quick Pro Tools session and recorded them both at the same
> time from the same key hit. The 24-bit zipped file with both sounds
> separate is about 2MB. That is probably too large for me to send to the
> reflector. Shall I send you a copy directly? I'm attaching the shorter,
> 16-bit version here, but at 350K your reflector may bounce it. Do you
> have an ftp site somewhere where I could drop audio like this? Maybe
> even in CVS somewhere?
> 
> Mark
> 
> 

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

On Tue, 2003-10-28 at 11:32, be...@ga... wrote:

> > 
> > And what's the current legal state of the 'stream from disk' patent? Has
> > anyone determined if this is a problem for this tool? 
> 
> 
> In 1991-1992 I worked for a small italian multimedia company
> Digimail S.r.l ...
<SNIP>
> ...I resided in the US I would be 100% ok).

<hehe!!> Sore spot, 'eh?! ;-) (Just joking! I get it's important AND
that it's a pain...)

> The disk streaming part was entirely developed by me (see old evo sampler
> versions about 3 years ago), I take the full resposibilities for that,
> so other developers do not need to fear anything related to this topic.

Great.
> 
> If you feel you are breaking a patent just don't use linuxsampler or if you
> want we firewall the server in a way that only EU people can download the code.
> Do you want this ?
> (of course the previous sencence was meant to put between <SARCASM></SARCASM>
> tags :-) )

Benno,
   This is completely a non-issue for me. It was nothing other than a
question. I have no personal position on patents, other than I hate
writing them. I hold some number (4, 5?) of U.S. patent, all hardware
related. They are just something I do for the companies I work for as a
condition of employment. Left to my own devices I'm far too lazy to
bother! ;-)

> 
> Plus try to think logically: if this patent was really non bogus then
> why were not Steinberg (Halion) and NI (Kontakt) sued out of the market.
> NI appeared very late on the audio scene but seems that most of 
> disk based sampling users are switching to Kontakt.

My understanding was that Kontakt still does not really stream from
disk, but I may be wrong about this. That was from Northern Sounds
recently, but it's just talk, not a legal statement by anyone who knows.


> Can we get back to linuxsampler technicals ?

:-) YES!! :-)


> We will use our own performance file format (perhaps XML).
> LS is not a GSt copy it only loads GIG files just like many other
> softsamplers.

Perfectly OK. gsp files are easy to build and are completely dependent
on the Sampler. 
> 
> PS: Mark do not take my rant personally it is just that I hear the same
> questions popping up again and again and I'm amazed that people do not
> realize how weak a patent about "loading a piece of file in RAM"  is.

Certainly. I didn't take it the least bit personally. Please don't take
offense in the future when 100's of people coming from years of GSt
background ask the same questions. Take some time and write a position
statement on it today, put it on the web site and let's just point
people towards it. The only thing I can promise you is that I'm not
going to be the last to ask it!! ;-)

SoundFont/DLS2/Gig (was Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity)

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

On Tue, 2003-10-28 at 05:48, Robert Jonsson wrote:
> Tuesday 28 October 2003 14.22 skrev be...@ga...:
> >
> > > - soundfont support, for now I'm perfectly happy with gig support, I
> > > wonder how hard it would be to add soundfont support though..?
> >
> > Well soundfont offers quite some modulation possibilities
> > (Peter Hanappe and Josh Green know this better than anyone).
> > I guess for now if you want SF2 it is better to use fluidsynth.
> > SF2 is IMHO a bit limited and linuxsampler aims at the professional
> > sampling domain so our priority is to make .GIG working. (at a later stage
> > we will try to add 24bit sample in Halion / Kontakt formats too).
> 
> yeah, soundfonts may not have the same professional feel, there are lots of 
> tome though, and some of the new ones allocate quite a lot of memory.
> >
> > Or alternatively when our GIG engine will be complete you can try to
> > convert your SF2 files using a conversion program like cdxtract
> > http://www.cdxtract.com (but relatively expensive $150).
> > Or better, integrate the fluid engine to linuxsampler :-)
> 
> yeah, I was thinking along those lines :) but I have no idea if it would be 
> feasible. 
> Josh are you here somewhere? Enlighten me :)
> 

Yep, I'm here :) When comparing GigaSampler versus SoundFont versus
DLS2, I don't think there is anything in particular that would make
GigaSampler more professional than these other formats, except for a few
key points: streaming of samples and > 16 bit audio. There is no reason
why streaming of samples couldn't be implemented with these other
formats, though. In the case of DLS2, its a really flexible format
(heck, GigaSampler used it, or rather trashed it in my opinion, would
have been nice if they had some sort of signature in the header). I
think DLS2/SF2 has more flexibility in some areas than GigaSampler
(particularly in the area of modulation, and extent of control values,
GigaSampler has rather restricted parameter ranges, at least from what I
have seen). DLS2 could theoretically contain any audio format that WAV
files can store, since the audio is stored as embedded WAV files. Its
just that the spec says that only 8bit or 16bit audio is defined as
being part of the standard.

Thinking of converting SoundFont or DLS2 files to GigaSampler gives me
the creeps. Doing it for your own purposes might make sense, but
distributing those GigaSampler files, means that less people can now use
that instrument patch, since its not an open standard. Maybe this will
change in the future, but I haven't quite come to like the GigaSampler
format yet. Maybe I just haven't worked with it enough. It would be nice
to see LinuxSampler built in a way that makes it modular enough to use
other formats easily.

I still envision my own project libInstPatch being usable for supporting
other formats for GigaSampler. It supports DLS2 and SF2 at this point
and GigaSampler to some extent and has a Python binding which I just
added. I've been working a lot lately though, so I haven't had a lot of
time to put toward these projects. But I hope that changes in the near
future. It would be nice to collaborate more on some of this stuff. The
C/C++ issue is probably going to come up again I'm sure, I'll look into
how hard it would be to add a C++ wrapper to libInstPatch, if that would
make it more appealing.

Nice to see some activity on this list. Cheers.
	Josh Green

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

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

> On Tue, 2003-10-28 at 09:31, be...@ga... wrote:
> 
> > excellent !
> > the mlock and sched_setscheduler warnings are becaue a regular user
> > cannot call these functions.
> > It might occur you get mlock errors as root too, but this means
> > that the preloaded RAM size (preloadsize * number of samples in a GIG
> file)
> > exceeds the available physical memory.
> > See my response to Robert.
> > 
> 
> Sorry that I haven't gone back through the archives yet, but educate me.
> Is this revision streaming from disk? I understand the architecture
> where the first portion of the loaded gig files are in memory and then
> GSt has to do a seek and start getting the rest of all notes being
> played. 
> 
> Is this what you are doing in this revision? 

Yes any disk based sample must use that method (Kontakt, Halion etc) because
the disk is too slow to provide low latency sample triggering.

> 
> And what's the current legal state of the 'stream from disk' patent? Has
> anyone determined if this is a problem for this tool? 


In 1991-1992 I worked for a small italian multimedia company
Digimail S.r.l that wrote games and CDROM multimedia for the Amiga
and CD32 (A set top box based on the Amiga).

They produced the italian version of the "Grolier Encyclopedia" multimedia
CDROM.
At that time I wrote low level routines needed for the audio part
of the encyclopedia.
One of them was exactly a set of routines that permitted to preload a small
 initial part of samples in RAM (in 8bit 8SVX format) and then when the
high level encyclopedia software requested it,
it could to trigger and start them them with low latency.
 while streaming the samples from a mass storage device (either HD or CDROM).

at that time PCs were only able to produce annoying BEEEEPs :-)

precaching initial parts in RAM is basically done by any kind of application
that streams data from an external source (be it from mass storage, network
etc). This is "technology" is as old as the mass storage device.
So then people talk about the RAM caching patent I'm amazed that people
take it seriously and have concerns if linuxsampler uses ram caching.

Should I sue the world because I have prior art in that field ? 
(the whole streaming routines were only a couple of dozen lines of 
MC68000 assembly).

You know pure software patents are illegal in EU anyway and most of our
developers (me, Christian, Steve H.) are living there so we are not doing
anything unlawful here.
(plus keep in mind I have prior art so even if I resided in the US I would
be 100% ok).
The disk streaming part was entirely developed by me (see old evo sampler
versions about 3 years ago), I take the full resposibilities for that,
so other developers do not need to fear anything related to this topic.

If you feel you are breaking a patent just don't use linuxsampler or if you
want we firewall the server in a way that only EU people can download the code.
Do you want this ?
(of course the previous sencence was meant to put between <SARCASM></SARCASM>
tags :-) )

Plus try to think logically: if this patent was really non bogus then
why were not Steinberg (Halion) and NI (Kontakt) sued out of the market.
NI appeared very late on the audio scene but seems that most of 
disk based sampling users are switching to Kontakt.
A potential killer for Giga.
(think about LS .... a bunch of poor open source developers, no money
to extract)

BTW: did you know Invision patented the playback of samples from RAM on a PC ?
This would probably make all softsynths/samplers in existence
(probably hundreds) illegal.
OTOH there is certainly lots of prior art here too and this is why 
Invision did not go against competitors ?
Seriously, I don't care.

I think the US is risking to be leaved behind the rest of the world in terms
of IT because the current bogus US software patent system is killing
 innovation.

Can we get back to linuxsampler technicals ?


> I typically load
> 16 libraries in GSt as a starting point. (Good Sounds.gsp) They
> encompass about 6GB of disk space - obviously too much for memory...
> 
> (And I do understand that you are only handling a single gig file and
> not a performance file at this time.)

We will use our own performance file format (perhaps XML).
LS is not a GSt copy it only loads GIG files just like many other
softsamplers.

PS: Mark do not take my rant personally it is just that I hear the same
questions popping up again and again and I'm amazed that people do not
realize how weak a patent about "loading a piece of file in RAM"  is.

I'd be curious where the world would be if Euler, Newton, Leibnitz etc all
patented their stuff  :-)

cheers,
Benno




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

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

On Tue, 2003-10-28 at 09:31, be...@ga... wrote:

> excellent !
> the mlock and sched_setscheduler warnings are becaue a regular user
> cannot call these functions.
> It might occur you get mlock errors as root too, but this means
> that the preloaded RAM size (preloadsize * number of samples in a GIG file)
> exceeds the available physical memory.
> See my response to Robert.
> 

Sorry that I haven't gone back through the archives yet, but educate me.
Is this revision streaming from disk? I understand the architecture
where the first portion of the loaded gig files are in memory and then
GSt has to do a seek and start getting the rest of all notes being
played. 

Is this what you are doing in this revision? 

And what's the current legal state of the 'stream from disk' patent? Has
anyone determined if this is a problem for this tool? I typically load
16 libraries in GSt as a starting point. (Good Sounds.gsp) They
encompass about 6GB of disk space - obviously too much for memory...

(And I do understand that you are only handling a single gig file and
not a performance file at this time.)

Thanks,
Mark

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

On Tue, 2003-10-28 at 09:31, be...@ga... wrote:
> PS: Mark, be careful to not scare off neighbours with strange noises while
> remotely operating LS via ssh  :-)
> 
> cheers,
> Benno

I have made this mistake before. (Actually wife and son sent running to
the movies.) Now the studio monitors are off and the only sounds would
be in headphones at my mix desk. ;-)

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

[Robert J. <rob...@da...>]

tisdagen den 28 oktober 2003 18.11 skrev Mark Knecht:
> Yes, works better as root:

ahh, ofcourse!

That was my problem also, no mlockall or sched messages.

Actually worked quite well without it, probably due to the relatively little 
load I managed to provoke.

/Robert

>
> root@Wizard linuxsampler # ./linuxsampler --numfragments 2
> --fragmentsize 256 --gig ../Gigs/Mellotron\ 8Voice.gig
> Initializing audio output...OK
> Loading gig file...OK
> Caching initial samples...OK
> Starting disk thread...OK
> Starting MIDI in thread...OK
> Disk thread running
> Starting audio thread...OK
> LinuxSampler initialization completed.
> Audio thread running
>
> On Tue, 2003-10-28 at 09:09, Mark Knecht wrote:
> > On Tue, 2003-10-28 at 07:58, be...@ga... wrote:
> > > you are correct, the hammerfall can deal only with
> > > number of fragments (period size) of 2.
> > > you can specify them on the commandline:
> > > --numfragments 2
> > > and set the frames per audio buffer too:
> > > --fragmentsize 256   (means each audio fragment uses 256 frames).
> > >
> > > can you try again with the --numfragments 2 and see if it works ?
> >
> > Benno,
> >    Again a step closer. Probably LSt working (I'm ssh'ed in, so I cannot
> > actually listen right now)  but still some messages I'd rather not see:
> >
> > mark@Wizard linuxsampler $ ./linuxsampler --numfragments 2
> > --fragmentsize 256 --
> > gig ../Gigs/Mellotron\ 8Voice.gig
> > Initializing audio output...OK
> > Loading gig file...OK
> > Caching initial samples...OK
> > Starting disk thread...OK
> > Starting MIDI in thread...WARNING, can't mlockall() memory!: Operation
> > not permitted
> > Disk thread running
> > OK
> > WARNING, can't mlockall() memory!: Operation not permitted
> > sched_setscheduler: Operation not permitted
> > Starting audio thread...OK
> > LinuxSampler initialization completed.
> > WARNING, can't mlockall() memory!: Operation not permitted
> > sched_setscheduler: Operation not permitted
> > Audio thread running
> >
> >
> > LinuxSampler stopped due to SIGINT
> > Segmentation fault
> > mark@Wizard linuxsampler $
> >
> >
> > This is on the standard Gentoo kernel. Possibly it doesn't have some
> > sort of kernel option or patch compiled in? Let me know what you think.
> >
> > Do I need to run as root?
> >
> > I will do some audio testing tonight.
> >
> > Good work!
> >
> > Mark
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

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

> Yes, works better as root:
> 
> root@Wizard linuxsampler # ./linuxsampler --numfragments 2
> --fragmentsize 256 --gig ../Gigs/Mellotron\ 8Voice.gig
> Initializing audio output...OK
> Loading gig file...OK
> Caching initial samples...OK
> Starting disk thread...OK
> Starting MIDI in thread...OK
> Disk thread running
> Starting audio thread...OK
> LinuxSampler initialization completed.
> Audio thread running
> 

excellent !
the mlock and sched_setscheduler warnings are becaue a regular user
cannot call these functions.
It might occur you get mlock errors as root too, but this means
that the preloaded RAM size (preloadsize * number of samples in a GIG file)
exceeds the available physical memory.
See my response to Robert.

Keep in mind that here is no concept of midi channel yet, so you can
just send midi data (note on/off) to any channel of the ALSA port
linuxsampler creates.

Let us know if when getting back home you are able to get out sound
of LS. 

PS: Mark, be careful to not scare off neighbours with strange noises while
remotely operating LS via ssh  :-)

cheers,
Benno


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

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

Yes, works better as root:

root@Wizard linuxsampler # ./linuxsampler --numfragments 2
--fragmentsize 256 --gig ../Gigs/Mellotron\ 8Voice.gig
Initializing audio output...OK
Loading gig file...OK
Caching initial samples...OK
Starting disk thread...OK
Starting MIDI in thread...OK
Disk thread running
Starting audio thread...OK
LinuxSampler initialization completed.
Audio thread running


On Tue, 2003-10-28 at 09:09, Mark Knecht wrote:
> On Tue, 2003-10-28 at 07:58, be...@ga... wrote:
> 
> > 
> > you are correct, the hammerfall can deal only with 
> > number of fragments (period size) of 2.
> > you can specify them on the commandline:
> > --numfragments 2
> > and set the frames per audio buffer too:
> > --fragmentsize 256   (means each audio fragment uses 256 frames).
> > 
> > can you try again with the --numfragments 2 and see if it works ?
> > 
> Benno,
>    Again a step closer. Probably LSt working (I'm ssh'ed in, so I cannot
> actually listen right now)  but still some messages I'd rather not see:
> 
> mark@Wizard linuxsampler $ ./linuxsampler --numfragments 2
> --fragmentsize 256 --
> gig ../Gigs/Mellotron\ 8Voice.gig 
> Initializing audio output...OK
> Loading gig file...OK
> Caching initial samples...OK
> Starting disk thread...OK
> Starting MIDI in thread...WARNING, can't mlockall() memory!: Operation
> not permitted
> Disk thread running
> OK
> WARNING, can't mlockall() memory!: Operation not permitted
> sched_setscheduler: Operation not permitted
> Starting audio thread...OK
> LinuxSampler initialization completed.
> WARNING, can't mlockall() memory!: Operation not permitted
> sched_setscheduler: Operation not permitted
> Audio thread running
> 
> 
> LinuxSampler stopped due to SIGINT
> Segmentation fault
> mark@Wizard linuxsampler $ 
> 
> 
> This is on the standard Gentoo kernel. Possibly it doesn't have some
> sort of kernel option or patch compiled in? Let me know what you think.
> 
> Do I need to run as root?
> 
> I will do some audio testing tonight.
> 
> Good work!
> 
> Mark

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

On Tue, 2003-10-28 at 07:58, be...@ga... wrote:

> 
> you are correct, the hammerfall can deal only with 
> number of fragments (period size) of 2.
> you can specify them on the commandline:
> --numfragments 2
> and set the frames per audio buffer too:
> --fragmentsize 256   (means each audio fragment uses 256 frames).
> 
> can you try again with the --numfragments 2 and see if it works ?
> 
Benno,
   Again a step closer. Probably LSt working (I'm ssh'ed in, so I cannot
actually listen right now)  but still some messages I'd rather not see:

mark@Wizard linuxsampler $ ./linuxsampler --numfragments 2
--fragmentsize 256 --
gig ../Gigs/Mellotron\ 8Voice.gig 
Initializing audio output...OK
Loading gig file...OK
Caching initial samples...OK
Starting disk thread...OK
Starting MIDI in thread...WARNING, can't mlockall() memory!: Operation
not permitted
Disk thread running
OK
WARNING, can't mlockall() memory!: Operation not permitted
sched_setscheduler: Operation not permitted
Starting audio thread...OK
LinuxSampler initialization completed.
WARNING, can't mlockall() memory!: Operation not permitted
sched_setscheduler: Operation not permitted
Audio thread running


LinuxSampler stopped due to SIGINT
Segmentation fault
mark@Wizard linuxsampler $ 


This is on the standard Gentoo kernel. Possibly it doesn't have some
sort of kernel option or patch compiled in? Let me know what you think.

Do I need to run as root?

I will do some audio testing tonight.

Good work!

Mark

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

> Benno,
>    One step closer:
> 
> mark@Wizard linuxsampler $ ./linuxsampler --gig ../Gigs/Mellotron\
> 8Voice.gig 
> Initializing audio output...Error setting number of periods. : Invalid
> argument
> mark@Wizard linuxsampler $ 
> 
> I think the Hammerfall stuff only handles period sizes of 2? Is that
> what's going on here? Or something else?

you are correct, the hammerfall can deal only with 
number of fragments (period size) of 2.
you can specify them on the commandline:
--numfragments 2
and set the frames per audio buffer too:
--fragmentsize 256   (means each audio fragment uses 256 frames).

can you try again with the --numfragments 2 and see if it works ?

as for using hw:1 just change the source and replace
plughw:0 with  plughw:1 and recompile (always do a make clean).

let us know.

Benno


> 
> Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




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

Re: [Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

On Tue, 2003-10-28 at 06:35, be...@ga... wrote:

> edit the file audioio.cpp
> and at line 59
> replace:
> pcm_name = strdup("hw:0,0");
> with:
> pcm_name = strdup("plughw:0,0");
> 
> make clean; make
> 

Benno,
   One step closer:

mark@Wizard linuxsampler $ ./linuxsampler --gig ../Gigs/Mellotron\
8Voice.gig 
Initializing audio output...Error setting number of periods. : Invalid
argument
mark@Wizard linuxsampler $ 

I think the Hammerfall stuff only handles period sizes of 2? Is that
what's going on here? Or something else?

Mark

Re: [Linuxsampler-devel] CVS

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

On Tue, 2003-10-28 at 05:49, Robert Jonsson wrote:
> Yeah, benno mentioned that it only works for cards capable of 16-bit data... 
> yet.
> 
> /Robert
> 
Benno,
   Is that true? If so, then can I use my on-board Via sound chip
somehow to run this? I could hook its analog output into an A/D and get
it back into my routing matrix if you think it will work. 

   If so, how would I tell LSt to use the second sound card? I don't see
any options at the command line when I add a --help modifier. Do you
support anything like -hw:1? Let me know.

Mark

[Linuxsampler-devel] 24bit multi-io audio card compatibility, Was: CVS

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

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


> 
> Robert,
>    Thanks. That downloaded and built fine, but it's not running:
> 
> 
> bash-2.05b$ cd LSt/linuxsampler/
> 
> bash-2.05b$ ./linuxsampler --gig ../Gigs/Mellotron\ 8Voice.gig 
> Initializing audio output...Error snd_pcm_hw_params_set_access: Invalid
> argument.
> bash-2.05b$ 
> 
> This machine is using the infamous HDSP 9652. I can try it on my GSt
> machine later this afternoon. That machine uses a Hammerfall Light and
> has lots of gig files.

This is because we currently use direct ALSA hw audio out and I've added
only code for 16bit/44.1kHz stereo to the AudioIO class.
Anyway as a quick solution you could try to
use the plughw: ALSA mode (where ALSA does the conversion between
audio fromat requested by the app and audio format supported by the card):

edit the file audioio.cpp
and at line 59
replace:
pcm_name = strdup("hw:0,0");
with:
pcm_name = strdup("plughw:0,0");

make clean; make

and try again.
Please let us know if it works.
If not then we will have to add code that supports the Hammerfall audio 
settings.
You could either try to do this by yourself (if you have the necessary skills)
or I could do this by myself. I have a Hammerfall 9656 here and I assume
that the audio wordsizes are the same so I guess code that runs on that box
runs on on the HDSP too.
Anyway I just hope plughw: works so it saves us additional work.

Well this is a classic case why jackd is so beneficial: you are freed from
the burden of supporting several kinds of audio interfaces, multichannel stuff,
 word sizes, sampling rates etc.
As said jackd support will come next but for now we need direct ALSA out
support for latency profiling reasons. This is fundamental for the initial
 development and tuning phase.
Mark if we don't get plughw: working I'll make sure to add 
HDSP support to the AudioIO class because you are very valuable and important
 for ironing out playback problems, compatibility with large GIG libs etc.

Let us know about plughw please. 
(the conversion in ALSA is pretty efficient so
the added overhead is quite low and the performance is almost as same
as when doing the conversion in the app itself).


Benno






> 
> - Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




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

Re: [Linuxsampler-devel] CVS

[Robert J. <rob...@da...>]

Yeah, benno mentioned that it only works for cards capable of 16-bit data... 
yet.

/Robert


Tuesday 28 October 2003 14.41 skrev Mark Knecht:
> On Tue, 2003-10-28 at 05:07, Robert Jonsson wrote:
> > Hi Mark,
> >
> > it sounds as if you got the version from sourceforge.net (as I did)
> >
> > the real version is at:
> >
> > cvs -z3
> > -d:pserver:ano...@cv...:/home/schropp/linuxsampler co
> > linuxsampler
> >
> > just typeing make after it downloaded worked for me.
> >
> > /Robert
>
> Robert,
>    Thanks. That downloaded and built fine, but it's not running:
>
>
> bash-2.05b$ cd LSt/linuxsampler/
>
> bash-2.05b$ ./linuxsampler --gig ../Gigs/Mellotron\ 8Voice.gig
> Initializing audio output...Error snd_pcm_hw_params_set_access: Invalid
> argument.
> bash-2.05b$
>
> This machine is using the infamous HDSP 9652. I can try it on my GSt
> machine later this afternoon. That machine uses a Hammerfall Light and
> has lots of gig files.
>
> - Mark
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity

[Robert J. <rob...@da...>]

Tuesday 28 October 2003 14.22 skrev be...@ga...:
...
>
> > - it segfaults when ctrl-c:ing out of the app.
>
> probably due to the incorrect stopping of threads when the CTRL-C handler
> is called, not a serious issue and probably very easy to fix.
> As said it would be more serious if linuxsampler segfaulted during playing.
> :-)

yeah, it's no big deal ;)

>
> > - on my system i get mlockall failures all the time, regardless of the
> > size of
> > the gig file and such... how much mem does LS allocate? (I've got 512mb
> > so it
> >
> > should work rather well I think. I can run debug compiled-muse together
> > with
> >
> > jack with no problems, which both do mlockall and occupy lots of
> > memory...)
>
> see diskthread.h:
> #define STREAM_BUFFER_SIZE 131072
> #define MAX_INPUT_STREAMS 64
>
> this means we can have max 64 disk streams (each voice if streamed from
> disk exactly needs one stream).
> We are talking about 16bit samples (2bytes) thus
> the streams occupy
> MAX_INPUT_STREAMS*STREAM_BUFFER_SIZE*2
>
> this is not an extremely high amount, in the above case 16MB

Definately not alot.... it may be that my machine has severely fragmented 
memory, I'll try rebooting it tonight..


<lots of interesting stuff shamelessly deleted>

> Even if there are already relatively cheap 64bit x86 boxes around, most
> notably the AMD Opteron / Athlon 64, Windows cannot use its full
> capabilities because the 64bit support is not it yet.
> Read this and you will see that Windows XP on AMD 64bit CPUs will take long
> long time to become a viable option: (a very bumby road I would say)
> http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp
>
> On the other hand Linux already runs on AMD 64bit CPUs and linuxsampler is
> 64bit compatible too.
> This means we can beat the windows sampler at their own game: linuxsampler
> already runs on performant 64bit boxes and what's more important we can
> handle much bigger amounts of RAM which is crucial for those wanting to
> load many samples at the same time.
> I guess once linuxsampler's engine is production ready and can play
> preexisting libraries correctly it will turn up on the windows people
> radarscreens, I assume even those using the windows samplers professionally
> because those are the people that need these monster installations with
> dozen, even hundreds of GBs worth of samples.

This could become a real killer feature! :)

> And I don't even touched the fact that linuxsampler could be clustred to
> provide sampler farms that can render thousand of voices and pipe them
> back in real time over ethernet without requiring expensive audio cards,
> midi interfaces etc for each cluster slave.

Hehe, okay, but I think you should save that for version 2 ;).

> > The things I miss are (probably mostly on the todo already)
> >
> > - gui (not strictly necessary)
>
> I have half finished a simple load&play GUI (load samples, assign them
> to midi channels and start playing, plus the GUI permits you to set
> basic settings like number of voices, RAM preload sizes etc, shows you
> activity and real time voice count etc).
> As I stated before linuxsampler is remotely controllable via TCP/IP which
> means the GUI can run on a different box and even on a different platform.
> What I am working on now is the remote control protocol which is a simple
> API that can be used by anone so anyone can build their favorite kind of
> remote control application.
> It can be a GUI, a text based application, a script, hardware buttons etc.
> The default GUI I will provide is written using the Qt library because of
> its portability. This will allow to run the GUI frontend on Windows and
> Mac too.
> This is because I'm assuming sooner or later we will see those linuxsampler
> clusters remote controlled by Windows PCs or Macs :-).
> Plus do not forget separating the frontend from the engine forces you
> to follow certain rules during coding which leads to a better quality
> of the code and helps to isolate errors and performance problems.

sounds great!
>
> > - jack output
>
> Of course. We will go as far that linuxsampler will not only export
> the main output (where all vocies will be mixed too) but single
> midi channel mix buffers which you can send to jack unprocessed
> and process the channels with your own FXes or record the tracks
> into eg ardour for further editing.
> But for now we only support direct ALSA out because we must first
> iron out potential latency problems.
> (if you put jack into the game then you cannot easily figure out
> if it's linuxsampler's or jack's fault).
> Divide et impera is the keyword here :-)
>
> > - soundfont support, for now I'm perfectly happy with gig support, I
> > wonder how hard it would be to add soundfont support though..?
>
> Well soundfont offers quite some modulation possibilities
> (Peter Hanappe and Josh Green know this better than anyone).
> I guess for now if you want SF2 it is better to use fluidsynth.
> SF2 is IMHO a bit limited and linuxsampler aims at the professional
> sampling domain so our priority is to make .GIG working. (at a later stage
> we will try to add 24bit sample in Halion / Kontakt formats too).

yeah, soundfonts may not have the same professional feel, there are lots of 
tome though, and some of the new ones allocate quite a lot of memory.
>
> Or alternatively when our GIG engine will be complete you can try to
> convert your SF2 files using a conversion program like cdxtract
> http://www.cdxtract.com (but relatively expensive $150).
> Or better, integrate the fluid engine to linuxsampler :-)

yeah, I was thinking along those lines :) but I have no idea if it would be 
feasible. 
Josh are you here somewhere? Enlighten me :)

>
> > - hmmm I think I ran it as an ordinary user (with pretty good results),
> > it occurs to me that SCHED_FIFO should not be available then. LS uses
> > SCHED_FIFO
> >
> > right? Should it complain if it can't set it? (this may be a
> > misconception of
> >
> > mine though)
>
> In theory it should complain:
>     if (sched_setscheduler(0, SCHED_FIFO, &schp) != 0) {
>         perror("sched_setscheduler");
>         return -1;
>     }
>
> anyway sched_setscheduler() is deprecated because for threads one should
> use pthread_attr_init() to set priorities.
> I heard rumors that sched_setscheduler() does not work correctly on
> recent threading libraries but I cannot confirm it.

It may be all my fault, I may just as well have run as root out of habit, I 
run most audio stuff as root...

>
> > ----
> > And finally, a wish. I think this mailinglist is too quiet, it's hard to
> > know
> >
> > if there is any activity at all.
> >
> > May I propose that you guys start announcing cvs checkins on this list?
>
> We will certainly announce new (relevant) CVS checkins on the list
> (manually).
> Regarding myself I'm working on the GUI/remote control protocol and it will
> take some time to make it work well, document etc so I guess I will not
> check in new stuff before 1-2 weeks. Perhaps Christian will add some stuff
> meanwhile and I'm sure he will announce it on this mailing list.

Release early, release often :) repeat the mantra.  Though I'm happy if it 
atleast compiles ;)

/Robert

Re: [Linuxsampler-devel] CVS

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

On Tue, 2003-10-28 at 05:07, Robert Jonsson wrote:
> Hi Mark,
> 
> it sounds as if you got the version from sourceforge.net (as I did)
> 
> the real version is at:
> 
> cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler 
> co linuxsampler
> 
> just typeing make after it downloaded worked for me.
> 
> /Robert
> 

Robert,
   Thanks. That downloaded and built fine, but it's not running:


bash-2.05b$ cd LSt/linuxsampler/

bash-2.05b$ ./linuxsampler --gig ../Gigs/Mellotron\ 8Voice.gig 
Initializing audio output...Error snd_pcm_hw_params_set_access: Invalid
argument.
bash-2.05b$ 

This machine is using the infamous HDSP 9652. I can try it on my GSt
machine later this afternoon. That machine uses a Hammerfall Light and
has lots of gig files.

- Mark

Re: [Linuxsampler-devel] Correct sustain pedal emulation (midi hold controller) ?

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

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

> On Tue, 2003-10-28 at 02:12, be...@ga... wrote:
> > Giga seems to have a velocity dynamics problem too.
> 
> Keep in mind that Warren's data here is 3 years old. There have been
> numerous upgrades to GSt. We should take his MIDI file and process out
> the same data, both with GSt and LinuxSampler for verification. Sometime
> this week I will try and do that.
> 
> (I have the Trachtman piano BTW)

ok, if the data is obsoleted the ignore that.
But yes, that you will be able to do A/B tests with the Trachtman piano 
will be very valuable. As always thanks for your contributions Mark.
Keep in mind that volume control is not supported yet in Christian's
articulation stuff so I guess it does not make sense yet to perform 
extensive A/B tests.
Christian what are your plans with the volume articulation ?
Or are there other issues to solve first ?

> 
> > See the very useful comments (with .MID and .GIG test files that show the
> issue)
> > from Warren Trachtman, the maker of the Trachtman Piano for Giga.
> > He talks about the sustain polyphony problem and the piano release mode
> that
> >  does not seem to work.
> 
> But he does give a clue as to what the 'piano release mode' is supposed
> to do, in his mind anyway. That's helpful.

yes.

> 
> > 
> > http://www.wstco.net/gigaissues/
> > 
> > Christian take these velocity issues into account when adding
> > volume support to linuxsampler.
> > 
> > Returning to the pedal polyphony problem: we could provide both
> >  the unlimited voices mode and a limited one, eg you say max 4
> >  voices per key this means if you keep hitting the same key you
> >  if there are more than 4 voices active the older notes will quickly 
> > fade out keeping the polyphony within limits.
> 
> Stay open and have ideas. I think the right answers will likely come
> down to how the sampler plays and what it sounds like. Finding the best
> solutions may come only when we get more musicians involved.

I agree, first make it simple (eg. no limits about the voices
that can be played on a single key) and then extend it.
What were these famous Microsoft tactics again ?
Embrace and extend ? :-)

> Hi,
>   I downloaded (I think) the CVS code. How do I build it? No INSTALL
> instruction file, so I tried:
>
> make -f Makefile.am

We moved away from sourceforge (many are still trying to check out
from sf.net :-) ):

this is the correct command to fetch the CVS:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler co
linuxsampler

cheers,
Benno

> 
> - Mark
> 
> 
> 




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

Re: [Linuxsampler-devel] testing of linuxsampler and cvs activity

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

Scrive Robert Jonsson <rob...@da...>:

> Hi guys,
> 
> I tried linuxsampler yesterday with the aid of benno, looks great! 
> 
> cpu load was low and it seemed pretty stable.
> 
> I encountered a few irks that according to benno are known issues, i'll list
> 
> them just for the record:
> 
> - clicks when doing note_off

this is because the sample is cutoff hard without any release envelope because
the enveloping stuff is still missing. So it is not an error.

> - trying the original gigapiano it sounded very strange when playing hard. To
> 
> me it sounded as if it the samples where played from the wrong key (one 
> octave up), benno told me there where issues with the midimapping which may 
> explain this.

yes exactly, Christian will add the complete articulation implementation
 soon so these strange effects will go away.
(actually libgig supports full articulation, it's linuxsampler that does not
yet honor all the values).

> - it segfaults when ctrl-c:ing out of the app.

probably due to the incorrect stopping of threads when the CTRL-C handler
is called, not a serious issue and probably very easy to fix.
As said it would be more serious if linuxsampler segfaulted during playing. :-)

> - on my system i get mlockall failures all the time, regardless of the size
> of 
> the gig file and such... how much mem does LS allocate? (I've got 512mb so it
> 
> should work rather well I think. I can run debug compiled-muse together with
> 
> jack with no problems, which both do mlockall and occupy lots of memory...)

see diskthread.h:
#define STREAM_BUFFER_SIZE 131072
#define MAX_INPUT_STREAMS 64

this means we can have max 64 disk streams (each voice if streamed from
disk exactly needs one stream).
We are talking about 16bit samples (2bytes) thus
the streams occupy
MAX_INPUT_STREAMS*STREAM_BUFFER_SIZE*2

this is not an extremely high amount, in the above case 16MB

most of the memory is consumed by the pre-cached initial parts of the samples.

see audiothread:
#define NUM_RAM_PRELOAD_SAMPLES

normally we set this value to 65536, which means for mono 16bit samples
we preload 65536*2=128KB of memory for each sample.
If the .GIG contains 1000 samples we use 128KB*1000= about 128MB of memory.
For stereo samples you must multiply the number by 2.
(in the above case 256KB of memory per stereo sample).
Preloading 65536 samples means 1.48secs of samples at 44.1kHz.
This is needed to overcome the delay that occurs for the disk thread
filling up the ringbuffers where the remaining part of the sample will
be streamed from.
The most critical case occurs when you start lots of notes at the same
time. Eg assume we have 50 samples (all different) and start them all
at the same time. This means that within 1.48secs (the RAM part of the sample),
the disk thread has to fill at least some samples in ALL 50 ringbuffers
associated to the voices. This means that in the above case the disk thread
might fail to meet the deadlines and you would risk that the audio thread
wants to fetch the audio data from the diskstream ringbuffers but the data
has not been loaded yet, leading to an error condition (we opted for note cutoff
and report the error).
The solution to this is tuning the disk streaming (there is room for improvement
by cutting read() sizes in critical situations but I will add this stuff at a
later stage), installing faster disks or increase the size of the part of sample
we preload in RAM. 
All disk based samples like giga,kontakt,halion have this problem when
many voices are triggered simultaneously and often the only solution is to
increase the RAM preload size which has the disadvantage that you can load
fewer sample libraries at the same time.
People that make extensive use of disk based sampler often have machines
with 1-2GB RAM to load as much sample libraries as possible.
There are sample libraries that require a minimum of 0.5-1GB to be loaded.
(the size of these libs is often 2-4GB).
For example NI Kontakt while having more features and offering better sample
 manipulation tools than Giga, is not that performant when it comes to streaming
like Giga (giga uses kernel based streaming, special low latency GSIF drivers
etc). This means in Kontakt you have often to increase preload sizes to up to
600KB which greatly reduces the size and number of sample libraries you can
load at the same time.
You know ... 32bit x86 boxes hit the wall at 1-2GB RAM because of the limited
 addressing space but many users using a disk based sampler would like to
install more ram, perhaps 8,16GB and more.
Even if there are already relatively cheap 64bit x86 boxes around, most notably
 the AMD Opteron / Athlon 64, Windows cannot use its full capabilities because
 the 64bit support is not it yet. 
Read this and you will see that Windows XP on AMD 64bit CPUs will take long long
time to become a viable option: (a very bumby road I would say)
http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp

On the other hand Linux already runs on AMD 64bit CPUs and linuxsampler is
64bit compatible too.
This means we can beat the windows sampler at their own game: linuxsampler
already runs on performant 64bit boxes and what's more important we can handle
much bigger amounts of RAM which is crucial for those wanting to load many
samples at the same time.
I guess once linuxsampler's engine is production ready and can play
preexisting libraries correctly it will turn up on the windows people 
radarscreens, I assume even those using the windows samplers professionally
because those are the people that need these monster installations with
dozen, even hundreds of GBs worth of samples.
And I don't even touched the fact that linuxsampler could be clustred to
provide sampler farms that can render thousand of voices and pipe them
back in real time over ethernet without requiring expensive audio cards,
midi interfaces etc for each cluster slave.

Only time will tell we we will remain a niche product or we will get 
high visibility. For now let's make work the basic engine perfectly.


Returning to you mlockall problem:
try to lower the NUM_RAM_PRELOAD_SAMPLES eg to 16384 (do a make clean
because there are some dependencies missing in the Makefile).

This could help but keep in mind if you preload fewer samples from disk
you risk to run into the problem described above where the disk thread
is unable to fill the ringbuffer in time, leading to note cut-offs.

> 
> All in all, this looks set to be a real killer app! :)

We're all working hard to make it happen.
As said every contribution count, not only code contributions.
Ideas, testing, debugging, advices from musicians, sampler/samplelibrary
 experts all count.

> 
> The things I miss are (probably mostly on the todo already)
> 
> - gui (not strictly necessary)

I have half finished a simple load&play GUI (load samples, assign them
to midi channels and start playing, plus the GUI permits you to set
basic settings like number of voices, RAM preload sizes etc, shows you
activity and real time voice count etc).
As I stated before linuxsampler is remotely controllable via TCP/IP which
means the GUI can run on a different box and even on a different platform.
What I am working on now is the remote control protocol which is a simple
API that can be used by anone so anyone can build their favorite kind of 
remote control application.
It can be a GUI, a text based application, a script, hardware buttons etc.
The default GUI I will provide is written using the Qt library because of
its portability. This will allow to run the GUI frontend on Windows and 
Mac too.
This is because I'm assuming sooner or later we will see those linuxsampler
clusters remote controlled by Windows PCs or Macs :-).
Plus do not forget separating the frontend from the engine forces you
to follow certain rules during coding which leads to a better quality
of the code and helps to isolate errors and performance problems.


> - jack output

Of course. We will go as far that linuxsampler will not only export
the main output (where all vocies will be mixed too) but single
midi channel mix buffers which you can send to jack unprocessed
and process the channels with your own FXes or record the tracks
into eg ardour for further editing.
But for now we only support direct ALSA out because we must first
iron out potential latency problems.
(if you put jack into the game then you cannot easily figure out
if it's linuxsampler's or jack's fault).
Divide et impera is the keyword here :-)

> - soundfont support, for now I'm perfectly happy with gig support, I wonder 
> how hard it would be to add soundfont support though..?

Well soundfont offers quite some modulation possibilities 
(Peter Hanappe and Josh Green know this better than anyone).
I guess for now if you want SF2 it is better to use fluidsynth.
SF2 is IMHO a bit limited and linuxsampler aims at the professional sampling
 domain so our priority is to make .GIG working. (at a later stage we will
try to add 24bit sample in Halion / Kontakt formats too).

Or alternatively when our GIG engine will be complete you can try to
convert your SF2 files using a conversion program like cdxtract
http://www.cdxtract.com (but relatively expensive $150).
Or better, integrate the fluid engine to linuxsampler :-)

> 
> - hmmm I think I ran it as an ordinary user (with pretty good results), it 
> occurs to me that SCHED_FIFO should not be available then. LS uses SCHED_FIFO
> 
> right? Should it complain if it can't set it? (this may be a misconception of
> 
> mine though)

In theory it should complain:
    if (sched_setscheduler(0, SCHED_FIFO, &schp) != 0) {
        perror("sched_setscheduler");
        return -1;
    }

anyway sched_setscheduler() is deprecated because for threads one should
use pthread_attr_init() to set priorities.
I heard rumors that sched_setscheduler() does not work correctly on
recent threading libraries but I cannot confirm it.


> 
> ----
> And finally, a wish. I think this mailinglist is too quiet, it's hard to know
> 
> if there is any activity at all.
> 
> May I propose that you guys start announcing cvs checkins on this list?

We will certainly announce new (relevant) CVS checkins on the list 
(manually).
Regarding myself I'm working on the GUI/remote control protocol and it will
take some time to make it work well, document etc so I guess I will not
check in new stuff before 1-2 weeks. Perhaps Christian will add some stuff
meanwhile and I'm sure he will announce it on this mailing list.

BTW: for those that wantet to check out the CVS source and did not
find the exact location here is how to get the sources:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler co
linuxsampler

cheers,
Benno


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

Re: [Linuxsampler-devel] CVS

[Robert J. <rob...@da...>]

Hi Mark,

it sounds as if you got the version from sourceforge.net (as I did)

the real version is at:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler 
co linuxsampler

just typeing make after it downloaded worked for me.

/Robert


Tuesday 28 October 2003 14.03 skrev Mark Knecht:
> Hi,
>    I downloaded (I think) the CVS code. How do I build it? No INSTALL
> instruction file, so I tried:
>
> make -f Makefile.am
>
> which produced a executable configure file, but then attempting to run
> that configure file failed:
>
> bash-2.05b$ ./configure
> creating cache ./config.cache
> ./configure: line 541: syntax error near unexpected token
> `LinuxSampler,0.0.1'
> ./configure: line 541: `AM_INIT_AUTOMAKE(LinuxSampler,0.0.1)'
> bash-2.05b$
>
>
> This is on Gentoo. The system is very up to date.
>
> - Mark
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] CVS

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

Hi,
   I downloaded (I think) the CVS code. How do I build it? No INSTALL
instruction file, so I tried:

make -f Makefile.am

which produced a executable configure file, but then attempting to run
that configure file failed:

bash-2.05b$ ./configure 
creating cache ./config.cache
./configure: line 541: syntax error near unexpected token
`LinuxSampler,0.0.1'
./configure: line 541: `AM_INIT_AUTOMAKE(LinuxSampler,0.0.1)'
bash-2.05b$ 


This is on Gentoo. The system is very up to date.

- Mark