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

Re: [Linuxsampler-devel] Lates CVS commit

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

Es geschah am Freitag, 5. M=E4rz 2004 22:35 als Rui Nuno Capela schrieb:
> Hi,
>
> > 	- I'm a bit disappointed about it's runtime efficiency
>
> In terms of code-path and resource efficiency, I humbly think that my raw
> approach, based on strtok can't be beaten ;)

I suggest we'll wait until we have a GUI so we can really test how it acts.=
 If=20
it performs really bad than we'll replace the parser by another solution, b=
ut=20
I would still then use another parser generator instead of a hand crafted=20
parser implementation. Keep in mind that the current protocol (as defined i=
n=20
the current, 4th draft) has only about perhaps 10% or less of the complexit=
y=20
it will have in one or two years (e.g. think about the planned recompilatio=
n=20
feature, all the modularity features...). And finally compare e.g. a Pascal=
=20
compiler written in BNF with a hand crafted Pascal compiler.

> > 	- Implemented LSCP network server (only single threaded so far,
> >         thus is only capable to handle one connection at one time),
>
> My liblscp code (http://www.rncbc.org/ls) has all this put together; is
> multi-client and multi-threaded. Remember that you shall only code the
> server-side callback function?
>
> OK. Now that some server code is already on linuxsampler I can dig it and
> probably reimplement it using "my" liblscp approach :)

The actual problem is not the server itself, but synchronization issues wit=
hin=20
the engine and modifications that have to be done to the scanner when it=20
comes to more than one nework connections. Not a big deal either, but it=20
means work and I would rather spend the time in other things at the moment.

Regarding efficiency of a multi threaded server I was thinking if a 0..n=20
threads solution would be good idea at all. It might be better to use a fix=
ed=20
amount of threads (e.g. 10 for max. 10 fronteds simultaniously) _ALL_ start=
ed=20
when LS is launched, then sending them all to sleep and just wake up one of=
=20
them in case of a connection. This avoids memory allocation on runtime and=
=20
avoids that our realtime thread might get in trouble.

If you like to work on the multi-threaded extension of the server Rui, I wo=
uld=20
appreciate that (less work for me ;)  but I would definitely prefer you to=
=20
work on a basic GUI first. We really lack some screenshots. ;)

And one last thing: I would prefer to keep the server implemented in C++.

Rui, if you like to checkin a new module to CVS (e.g. liblscp or your GUI),=
=20
please let me know before you do it, because I have to set up a script on t=
he=20
CVS server before.

> > P.S. It's time for a frontend... :)
>
> Yes it is ;)

That's what I wanted to hear! Now it's your turn! :)

CU
Christian

Re: [Linuxsampler-devel] Lates CVS commit

[Rui N. C. <rn...@rn...>]

Hi,

> 	- I'm a bit disappointed about it's runtime efficiency

In terms of code-path and resource efficiency, I humbly think that my raw
approach, based on strtok can't be beaten ;)

> 	- Implemented LSCP network server (only single threaded so far,
>         thus is only capable to handle one connection at one time),

My liblscp code (http://www.rncbc.org/ls) has all this put together; is
multi-client and multi-threaded. Remember that you shall only code the
server-side callback function?

OK. Now that some server code is already on linuxsampler I can dig it and
probably reimplement it using "my" liblscp approach :)

Of course I'll welcome comments on this.

>
> P.S. It's time for a frontend... :)
>

Yes it is ;)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Lates CVS commit

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

On Fri, 2004-03-05 at 07:09, Christian Schoenebeck wrote:
<SNIP>
> CU
> Christian
> 
> P.S. It's time for a frontend... :)
> 
Boy did that P.S. put a smile on my face! ;-)

[Linuxsampler-devel] Lates CVS commit

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

Changes:

        - Implemented parser for the LinuxSampler control protocol (LSCP) by
	  using flex / bison (where src/network/lscp.l is the input file for lex /
	  flex and src/network/lscp.y is the input file for yacc / bison). Parser and
	  scanner can be regenerated by 'make parser' (only necessary though if one
	  of the two input files where modified).
	  To be honest I'm not quite sure so far if this parser solution is a good
	  choice, especially because I'm a bit disappointed about it's runtime
	  efficiency (a main problem is that lexical analyzer and semantic analyzer
	  are separated which is a big disadvantage for the parser generator in
	  regards of optimization), but this lex/yacc soultion has the advantage
	  of defining the protocol on a higher level and is thus easier to maintain
	  in regards of a growing and possible complex protocol. We'll see...
	  If somebody's not familiar with lex/yacc, I can give an introduction to the
	  current LSCP implementation in a short mail if demanded.
	  If somebody has a suggestion for another parser generator, let me know!

	- Implemented LSCP network server (only single threaded so far, thus is only
	  capable to handle one connection at one time), LSCP server will be launched
	  if LinuxSampler was started with the new "--server" flag. So far I
	  implemented the following LSCP commands:

		* "LOAD INSTRUMENT"
		* "GET CHANNEL VOICE_COUNT"
		* "GET CHANNEL STREAM_COUNT"
		* "GET CHANNEL BUFFER_FILL"
		* "SET CHANNEL VOLUME"
		* "RESET CHANNEL"

	  In src/network/lscpserver.cpp there already all methods which will be
	  called in case of the respective network command. But most of them
	  currently just return a "ERR:0:Not implemented yet" error message, so these
	  methods need to be "wired" now with the engine and have to return a
	  meaningful response message. If anybody likes to implement one of those
	  methods I would appreciate that! (Vladimir perhaps?)	  

	- disk thread now started within the engine

CU
Christian

P.S. It's time for a frontend... :)

[Linuxsampler-devel] LinuxSampler control protocol (4th draft)

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

Hi!

I updated the protocol document:

        http://cvs.linuxsampler.org/~schropp/linuxsampler/draft-linuxsampler-protocol-03.pdf
        http://cvs.linuxsampler.org/~schropp/linuxsampler/draft-linuxsampler-protocol-03.sxw

Seems the password on the webserver is outdated so I wasn't yet able to upload 
it on the official webserver and update the download page, Benno can you do 
that?

Major changes:

	- "Load instrument" command now looks like this:
	   "LOAD INSTRUMENT <filename> <instr-index> <sampler-chan>", where
	   <instr-index> should be replaced by the index of the instrument in the
	    instrument file
	- multi line responses are now terminated by a "." line like in SMTP (this
	  accounts e.g. for "GET CHANNEL INFO" or "GET ENGINE INFO" commands)
	- added "RESET CHANNEL <sampler-chan>" command which resets the engine on the
	   given sampler channel (means kills all active voices and streams and
	   resets all control and status variables)
	- added "QUIT" command, which closes the network connection and is especially
	  handy for manual telnet connections to LinuxSampler

Suggestions, improvements and corrections regarding the LinuxSampler Control 
Protocol (LSCP) always appreciated!

CU
Christian

[Linuxsampler-devel] White Grand .GIG (evaluation) online

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

Worra (maker of the 32 layer White Grand piano) wrote on the northernsounds.com
forum:

The Gigastudio version of the White Grand are now available for download so now
you can experience the sound and 32 velocity splits/note yourself.
You'll get two full complete octaves plus all the C's!
The file is still quite big, so I've divided it into 50Mb chunks. You also need
WinRar to unpack the files.
Since this is a new way for me to let people evaluate samples, I need some
feedback from you.

click here for the entire message and download links:
http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php?ubb=get_topic;f=3;t=007343

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


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

Re: [Linuxsampler-devel] Re: EG

[Vladimir S. <ha...@so...>]

Christian,

Cool!
Nice diagram. Way better than my ascii graph :)

One little thing i noticed is that it doesn't go from attack_hold into 
release.
I had the same question at some point and i found a few gigs with 
attackhold=1.
I've played them in Gst and it certainly goes from attack_hold into release.
've used a short script and libgig to find gigs to try:
#!/bin/bash
#
for gig in *.[gG][iI][Gg]; do
#echo lookin at gig: $gig
ishold=`gigdump $gig|grep "EG1Hold=1"`
if [ "$ishold" != "" ]; then
        echo "Found gig with EG1Hold=1: $gig"
fi
done

Basically none of the gigs i found played correctly until i introduced a 
transition from attack_hold into release. I'm not sure if that's 
actually correct or not but GSt does it so i'm assuming it is.

Hope this helps!
Regards,
Vladimir.

PS: My jack seems to go crazy only after i run out of voices. It then 
continues to play "out of tune" until i run out of voices again at that 
point it chanes tune again and sometimes recovers sometimes becomes even 
more out of tune . . . Eventually after i run out of voices a few times 
in a row it recovers :)

PPS: Sorry i didn't pay attention to the jitter stuff. I thought it was 
just a small merge and didn't reallize it had to be implemented for all 
stages.

Christian Schoenebeck wrote:

>Es geschah am Sonntag, 8. Februar 2004 03:51 als Vladimir Senkov schrieb:
>  
>
>>Hi Christian,
>>
>>Here is the cumulative patch against latest CVS.
>>It includes:
>>1) ADSDR implementaion (includes a hack for "post release sustain")
>>    
>>
>
>I had a look at your patch, but it wasn't applicable, sorry. Especially due to 
>the lack of event handling in the new states I chose another way. The problem 
>is, it would introduce jitter. You might think this is not that important, 
>but think about the "freeze" scenario where you might have very big fragment 
>sizes. Anyway, this is the state diagram of the new envelope generator 
>(already in CVS):
>
>	http://www.linuxsampler.org/doc/engines/gig/eg1.pdf
>
>Please have a look at it (Vladimir, Mark) and let me know if you think it's 
>incorrect compared to the EG from Gst.
>
>  
>
>>2) Command line options (alsa card selection, jack playback autoconnect
>>and alsa samplerate)
>>    
>>
>
>I applied that to CVS, I only did some minor cosmetic adjustment.
>
>  
>
>>3) I've fixed EOL characters in jackio.h
>>    
>>
>
>I fixed that manually on the CVS server today for all files that had that 
>problem, so that CVS history keeps consistent.
>
>  
>
>>Regards,
>>Vladimir.
>>    
>>
>
>Thanks Vladimir!
>
>  
>
>>PS: I've been playing with jack for a little while. Something strange is
>>going on. Sometimes, (maybe under load?) LS goes out of tune. It begins
>>to sound as if i had my card at 32KHz but LS was thinking it was at 48 . .
>>. It stays that way until i restart it. It never happened with alsa though.
>>I haven't been able to consistently reproduce this yet. Have you had
>>anything like this happening at all?
>>    
>>
>
>I never had that problem nor did I hear something about that. Anybody else 
>having this problem?
>
>CU
>Christian
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Linuxsampler-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>  
>

[Linuxsampler-devel] Re: linuxsampler make error

[Piotr S. <pe...@pl...>]

Christian Schoenebeck wrote:

>>I have loaded megapiano.gig file and have noticed, that there is a =
delay
>>between pressing the key on the midi-keyboard and sound. Is it poss=
ible
>>to change it?
>>   =20
>>
>
>Short answer: yes :)
>
>But unfortunately I can't guess what the acutal reason for your audi=
ble delay=20
>is. There are many possibilities. E.g.:
>
>=09- bad soundcard that doesn't supprt small audio fragment sizes
>
I have a terratec ewx 24/96 with giga sampler LE on windows and=20
fluidsynth on linux and I think they work well with this sound card.

>=09- incorrect interpretation of gig patch file informations
>
>The latter would be my fault, but unfortunately I don't know or have=
=20
>"megapiano",=20
>
I could send it to You, or leave on a ftp compressed with flacpak to=
=20
19MB if it does not break any law. This file was provided with giga=
=20
sampler on bundle software cd with my sound card. It sounds fine on=
=20
gigasampler and I even tried to build  a sf2 file with swami using=
=20
samples from it and it also sounded ok.

>so I can't tell you that at the moment. You should first check=20
>if your soundcard works acceptable with other linux realtime=20
>soft-synths/samplers. If that works, please repost your problem to t=
he=20
>linuxsampler-devel mailing list.
>

Thanks for the script.

What about this strange pitch schift?

Thanks again

Piotr

--=20
Kopalnia D=BCwi=EAku
Piotr Karol Sawicki=20
email: pe...@pl...
strona domowa: www.piotr.art.pl

[Linuxsampler-devel] Re: EG

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

Es geschah am Sonntag, 8. Februar 2004 03:51 als Vladimir Senkov schrieb:
> Hi Christian,
>
> Here is the cumulative patch against latest CVS.
> It includes:
> 1) ADSDR implementaion (includes a hack for "post release sustain")

I had a look at your patch, but it wasn't applicable, sorry. Especially due to 
the lack of event handling in the new states I chose another way. The problem 
is, it would introduce jitter. You might think this is not that important, 
but think about the "freeze" scenario where you might have very big fragment 
sizes. Anyway, this is the state diagram of the new envelope generator 
(already in CVS):

	http://www.linuxsampler.org/doc/engines/gig/eg1.pdf

Please have a look at it (Vladimir, Mark) and let me know if you think it's 
incorrect compared to the EG from Gst.

> 2) Command line options (alsa card selection, jack playback autoconnect
> and alsa samplerate)

I applied that to CVS, I only did some minor cosmetic adjustment.

> 3) I've fixed EOL characters in jackio.h

I fixed that manually on the CVS server today for all files that had that 
problem, so that CVS history keeps consistent.

> Regards,
> Vladimir.

Thanks Vladimir!

> PS: I've been playing with jack for a little while. Something strange is
> going on. Sometimes, (maybe under load?) LS goes out of tune. It begins
> to sound as if i had my card at 32KHz but LS was thinking it was at 48 . .
> . It stays that way until i restart it. It never happened with alsa though.
> I haven't been able to consistently reproduce this yet. Have you had
> anything like this happening at all?

I never had that problem nor did I hear something about that. Anybody else 
having this problem?

CU
Christian

Re: [Linuxsampler-devel] liblscp: A LinuxSampler Control Protocol implemetation

[Rui N. C. <rn...@rn...>]

Christian Schoenebeck wrote:
>
> I'm still wondering why so many people use the abbreviation 'al.' for
> 'alii'.  Kind of academic tradition? :)
>

;-)

>> A couple of weeks ago I've sent here a note about my early LSCP
>> (LinuxSampler Control Protocol) implementation, which I've named
>> liblscp.
>>
>> I've been kind of idle while waiting for comments about it,
>> before going any further, into GUI development that is.
>>
>> You can check it out from:
>>
>>     http://www.rncbc.org/ls/
>
> Seems to be down. Could you send me your current tarball?
>

Yep, it was down for quite an hour or so. The damn UPS just decided to
shutdown my server gracefully, but everything is now powered up as it
should.

Anyway, please find it here on attachment.

> Rui, I would like to split liblscp: completely removing the server side
> part from liblscp and move it directly into the LS engine codebase, so
> that liblscp is a convenient library for LS frontends only. I think this
> separation would make sense, because neither does LS need the client
> side of the lib, nor does any other application (LS frontend or
> whatever) need a 'server side' of LSCP.
>

OK, these are the only files that are server specific: lscp_server.h and
lscp_server.c (pretty obvious huh? :). Following this fashion,
lscp_client.h and lscp_client.c are the client frontends. All the rest are
common to both sides.

> Would you accept that Rui?
>

Of course. As I said, the current liblscp implementation is rather crude
and is just kind of some proof-of-concept. Nothing more.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

RE: [Linuxsampler-devel] voice stealing

[Vladimir S. <ha...@so...>]

Hi,

>> introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain
>> percentage of MAX_AUDIO_VOICES depending on how long the release
phase
>> is. If it's set to the same value as MAX_AUDIO_VOICES or higher, then
>> voice stealing will be disabled.

>I don't think that's a good idea. We would waste a big amount of
voices.

Agreed, but it takes time to release a voice and if we make a decision
to do so at the time when we need another (new voice) we'll not be able
to get a new voice unless there was some sort of reserve left.
The reserve will then have to be at least as large as the largest accord
you can take (10 for piano?!).
That's if we are single instrument only.

>> 2) When number of voices reaches the threshold and a new key is 
>> pressed, ls will try the following:
>>  a) locate voices on that same key and release all but the last one
of 
>> them

>No, you can't simply release all voices on a key.
>In case of .gig files there is flag called "SelfMask". If this flag is
set and 
>a key is triggered while there's still a voice active on that specific
key 
>and if the new voice is louder than the old one, then the old voice
should be 
>released. In case of this flag this should always be done, not only if
the 
>amount of free voices is low.

That's cool. I didn't know about this flag. This could work for some
cases. I could try to code that and see how that works.
But as far as I understand we still need a reserve of voices to be able
to release them (if that's going to be real release).

>If SelfMask is not set, I think we'll better use the whole amount of
voices 
>instead of your suggested threshold and if we then come into voice
shorteness 
>we could:
>	a) either pick the oldest voice (on that key / channel wide) or
>	b) pick the most silent voice (on that key / channel wide)
>
>and then without going into a release stage just take over this voice
object 
>and make a crossfade from the old to the new sample stream. That would
be 
>more friendly regarding polyphony and avoids click sounds.

That's an interesting idea. I'm sure we can come up with good ways on
how to pick a voice (maybe even make that configurable as Mark suggests)
but I'm not sure how crossfading will help. As far as I understand
crossfading, it involves a time interval and during that time interval
we'll have to have both old and new voices "alive". So that's similar to
playing old voice in release and playing new voice in attack then and
we'll have to have reserves again.

On the other hand, if we don't want the reserves and don't want the time
interval we could get the level from old voice and set it as preattack
for the new one and get rid of the old one without any time interval. IF
the level of the old voice was close to 0 that would actually sound OK.
But as the level of the old voice grows it will sound terrible as attack
stage of the new voice gets smaller and smaller and eventually
disappears. Could we then take a % of the old level then? If that % is
not large enough we will get clicks. If it's too big we'll get no attack
on new voice. I don't think this will work.

How is all this going to change when we actually play the release
samples? It will probably be best if we consider that now as well.

Regards,
Vladimir.

Re: [Linuxsampler-devel] voice stealing

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

On Wed, 2004-02-11 at 12:13, Christian Schoenebeck wrote:

> No, you can't simply release all voices on a key.

I agree with this.
> 
> In case of .gig files there is flag called "SelfMask". If this flag is set and 
> a key is triggered while there's still a voice active on that specific key 
> and if the new voice is louder than the old one, then the old voice should be 
> released. In case of this flag this should always be done, not only if the 
> amount of free voices is low.
> 
> If SelfMask is not set, I think we'll better use the whole amount of voices 
> instead of your suggested threshold and if we then come into voice shorteness 
> we could:
> 
> 	a) either pick the oldest voice (on that key / channel wide) or
> 	b) pick the most silent voice (on that key / channel wide)

I wonder if the concept of the SelfMask bit could be extended in some
way to LS overall, as a command line option, or later on a gig by gig
option in the GUI? I'm thinking I'd like the option to never have more
than 1 piano note being played on middle C even if the normal operation
of the gig file doesn't work that way. (And most of mine do not.)

Just an idea. It might make a good tool to study how the actual audio is
changed, or it could help a lot if one MIDI track was using a lot of
voices and not allowing other gigs to get their fair share.

> 
> and then without going into a release stage just take over this voice object 
> and make a crossfade from the old to the new sample stream. That would be 
> more friendly regarding polyphony and avoids click sounds.
> 
> Doubts? Other suggestions?
> 

Only that, in the spirit of pressing forward, we need to consider how
this will work when we get the ability to use multiple gigs at the same
time. If I have 8-12 gigs loaded (typical of my use of GSt) then how
many voices can be used by each gig? I'd like some control that says the
piano always gets a minimum 20 voices should it need them, the horns
always get 3 voices, a synth pad get 6, etc. This sort of control could
go a long way toward LS doing what the user wants instead of what it
thinks is the best, and masking could take over only when one gig is
using more than the allocated voice count more intelligently.

GSt offers nothing like this.

Just a thought.

Thanks,
Mark

Re: [Linuxsampler-devel] liblscp: A LinuxSampler Control Protocol implemetation

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

Es geschah am Mittwoch, 28. Januar 2004 13:45 als Rui Nuno Capela schrieb:
> Hi benno et al.

I'm still wondering why so many people use the abbreviation 'al.' for 'alii'. 
Kind of academic tradition? :)

> A couple of weeks ago I've sent here a note about my early LSCP
> (LinuxSampler Control Protocol) implementation, which I've named liblscp.
>
> I've been kind of idle while waiting for comments about it, before going
> any further, into GUI development that is.
>
> You can check it out from:
>
>     http://www.rncbc.org/ls/

Seems to be down. Could you send me your current tarball?

Rui, I would like to split liblscp: completely removing the server side part 
from liblscp and move it directly into the LS engine codebase, so that 
liblscp is a convenient library for LS frontends only. I think this 
separation would make sense, because neither does LS need the client side of 
the lib, nor does any other application (LS frontend or whatever) need a 
'server side' of LSCP.

Would you accept that Rui?

CU
Christian

Re: [Linuxsampler-devel] voice stealing

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

Es geschah am Sonntag, 8. Februar 2004 19:50 als Vladimir Senkov schrieb:
> Hi Everybody,
>
> I've been thinking about note stealing or as i'd like to call it "voice
> stealing".
> So far the following comes to mind:
> 1) When number of voices reaches max there will not be any time to
> release them, so we have to start releasing them earlier. I'm
> introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain
> percentage of MAX_AUDIO_VOICES depending on how long the release phase
> is. If it's set to the same value as MAX_AUDIO_VOICES or higher, then
> voice stealing will be disabled.

I don't think that's a good idea. We would waste a big amount of voices.

> 2) When number of voices reaches the threshold and a new key is pressed,
> ls will try the following:
>  a) locate voices on that same key and release all but the last one of them

No, you can't simply release all voices on a key.

In case of .gig files there is flag called "SelfMask". If this flag is set and 
a key is triggered while there's still a voice active on that specific key 
and if the new voice is louder than the old one, then the old voice should be 
released. In case of this flag this should always be done, not only if the 
amount of free voices is low.

If SelfMask is not set, I think we'll better use the whole amount of voices 
instead of your suggested threshold and if we then come into voice shorteness 
we could:

	a) either pick the oldest voice (on that key / channel wide) or
	b) pick the most silent voice (on that key / channel wide)

and then without going into a release stage just take over this voice object 
and make a crossfade from the old to the new sample stream. That would be 
more friendly regarding polyphony and avoids click sounds.

Doubts? Other suggestions?

CU
Christian

RE: [Linuxsampler-devel] voice stealing

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

Hi Peter,
On Mon, 2004-02-09 at 00:05, Peter E. Roos wrote:
> Hi Marek,
> 
> If you play a loud piano note with the sustain pedal down, and then a
> soft note, the loud note will have to continue ringing, the second
> softer note should not chop off this louder note.

But there's still dampening happening if you hit a note twice, perhaps
it's not going to dampen that note entirely if you hit a loud note and a
soft note afterwards, but it's still happening, it seems to me that it's
more the energy making the second note a bit louder.

Take an arbitrary string instrument, a guitar, violin, viola, cello,
harp - seems to me that they fit the 1 voice per note model.

Marek

> 
> Another important example is: with non-looped sounds, people often use
> the sustain pedal and hit the note again, as a trick to make the note
> longer (short doubling), before the first note reaches its normal end.
> 
> I know this is about note/voice stealing, when we are running out of
> available voices. So this may be a non-issue. But just to mention some
> typical effects/tricks that people use with samplers.
> 
> Regards,
> 
> Peter Roos
> 
> -----Original Message-----
> From: Marek Peteraj [mailto:ma...@na...] 
> Sent: Monday, February 09, 2004 2:02
> To: pet...@de...
> Cc: lin...@li...
> Subject: RE: [Linuxsampler-devel] voice stealing
> 
> 
> On Sun, 2004-02-08 at 23:45, Peter E. Roos wrote:
> > In any case the sustain pedal should bypass such an optimization  ;-)
> 
> Not if you're hitting the same note twice. There's no bypass happening
> on that note in any case, whether pedal down or not.
> 
> > 
> > I have read that GigaStudio has such an approach, but only when the
> > velocity of the second note is louder than the first,
> 
> That might be an idea, suppose that the energy of the resonance which
> has been dampened somehow carries over the next resonance thus it makes
> the note sound louder. Still talking about the piano though,
> well i'm not a physicist but anyway... :)
> 
> >  thus assuming it
> > will mask the disappearance of the first note. 
> 
> Which instrument would need more than one voice per note?
> 
> Marek
> 
> > Otherwise, with some
> > instrument, it may give a weird ending to the first note.
> > 
> > Peter Roos
> > 
> > -----Original Message-----
> > From: lin...@li...
> > [mailto:lin...@li...] On Behalf Of
> > Marek Peteraj
> > Sent: Monday, February 09, 2004 1:43
> > To: lin...@li...
> > Subject: Re: [Linuxsampler-devel] voice stealing
> > 
> > 
> > Hi Vladimir & all,
> > 
> > just wanted to ask, is there any reason why linuxsampler can't have
> just
> > one voice per note? For example suppose i've got a huge lib loaded
> with
> > long samples that need to be streamed from disk,  currently AFAIK if i
> > press a note and then press the same note again, i end up with 2
> > streams. But if you imagine an instrument such as a piano, a hammer
> > which hits a string at a given time is going to completely dampen the
> > previous string resonance at that time while causing a new resonance.
> > That seems like dismissing the old stream completely at the time i hit
> a
> > note and starting a new one hence you end up with a nice 1 voice per
> > note optimisation. Perhaps i'm wrong, just my imagination...
> > 
> > Marek
> > 
> > On Sun, 2004-02-08 at 19:50, Vladimir Senkov wrote:
> > > Hi Everybody,
> > > 
> > > I've been thinking about note stealing or as i'd like to call it
> > "voice 
> > > stealing".
> > > So far the following comes to mind:
> > > 1) When number of voices reaches max there will not be any time to 
> > > release them, so we have to start releasing them earlier. I'm 
> > > introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain
> 
> > > percentage of MAX_AUDIO_VOICES depending on how long the release
> phase
> > 
> > > is. If it's set to the same value as MAX_AUDIO_VOICES or higher,
> then 
> > > voice stealing will be disabled.
> > > 2) When number of voices reaches the threshold and a new key is
> > pressed, 
> > > ls will try the following:
> > >  a) locate voices on that same key and release all but the last one
> of
> > them
> > >  b) if that didn't yeld any results, go thru all keys and try same
> > >  c) if that didn't work either, try same as above but be more
> > aggressive 
> > > i.e. free the last voice as well.
> > > 
> > > What do you guys think? Any better ideas?
> > > I've been playing around with it and it seems to work OK. With max 
> > > voices set to 64 i've set the threshold to 48 and it seems to take
> > care 
> > > of most situations. Depending on how long the release phase is, it
> may
> > 
> > > need to be set to something lower (or max voices will have to be 
> > > increased). At some point we could add a clever algorithm to
> calculate
> > 
> > > the threshold automatically based on how long the release phase is 
> > > (average release time for all samples?)
> > > 
> > > I'm including a patch against latest CVS. This patch also includes
> > some 
> > > command line and EG changes. Christian will likely review those (but
> > not 
> > > the voice stealing part) next weekend and it might make it in some
> > shape 
> > > of form into the CVS, so please give it some testing also, if you
> have
> > 
> > > time. If you have trouble with voice stealing and just want to play 
> > > around with the EG you can turn off voice stealing by setting 
> > > AUDIO_VOICES_THRESHOLD to be same as MAX_AUDIO_VOICES in
> > audiothread.h.
> > > 
> > > Regards,
> > > Vladimir.
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> > 
> > 
> > 
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> > 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 

RE: [Linuxsampler-devel] voice stealing

[Peter E. R. <pet...@de...>]

Hi Marek,

If you play a loud piano note with the sustain pedal down, and then a
soft note, the loud note will have to continue ringing, the second
softer note should not chop off this louder note.

Another important example is: with non-looped sounds, people often use
the sustain pedal and hit the note again, as a trick to make the note
longer (short doubling), before the first note reaches its normal end.

I know this is about note/voice stealing, when we are running out of
available voices. So this may be a non-issue. But just to mention some
typical effects/tricks that people use with samplers.

Regards,

Peter Roos

-----Original Message-----
From: Marek Peteraj [mailto:ma...@na...] 
Sent: Monday, February 09, 2004 2:02
To: pet...@de...
Cc: lin...@li...
Subject: RE: [Linuxsampler-devel] voice stealing


On Sun, 2004-02-08 at 23:45, Peter E. Roos wrote:
> In any case the sustain pedal should bypass such an optimization  ;-)

Not if you're hitting the same note twice. There's no bypass happening
on that note in any case, whether pedal down or not.

> 
> I have read that GigaStudio has such an approach, but only when the
> velocity of the second note is louder than the first,

That might be an idea, suppose that the energy of the resonance which
has been dampened somehow carries over the next resonance thus it makes
the note sound louder. Still talking about the piano though,
well i'm not a physicist but anyway... :)

>  thus assuming it
> will mask the disappearance of the first note. 

Which instrument would need more than one voice per note?

Marek

> Otherwise, with some
> instrument, it may give a weird ending to the first note.
> 
> Peter Roos
> 
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...] On Behalf Of
> Marek Peteraj
> Sent: Monday, February 09, 2004 1:43
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] voice stealing
> 
> 
> Hi Vladimir & all,
> 
> just wanted to ask, is there any reason why linuxsampler can't have
just
> one voice per note? For example suppose i've got a huge lib loaded
with
> long samples that need to be streamed from disk,  currently AFAIK if i
> press a note and then press the same note again, i end up with 2
> streams. But if you imagine an instrument such as a piano, a hammer
> which hits a string at a given time is going to completely dampen the
> previous string resonance at that time while causing a new resonance.
> That seems like dismissing the old stream completely at the time i hit
a
> note and starting a new one hence you end up with a nice 1 voice per
> note optimisation. Perhaps i'm wrong, just my imagination...
> 
> Marek
> 
> On Sun, 2004-02-08 at 19:50, Vladimir Senkov wrote:
> > Hi Everybody,
> > 
> > I've been thinking about note stealing or as i'd like to call it
> "voice 
> > stealing".
> > So far the following comes to mind:
> > 1) When number of voices reaches max there will not be any time to 
> > release them, so we have to start releasing them earlier. I'm 
> > introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain

> > percentage of MAX_AUDIO_VOICES depending on how long the release
phase
> 
> > is. If it's set to the same value as MAX_AUDIO_VOICES or higher,
then 
> > voice stealing will be disabled.
> > 2) When number of voices reaches the threshold and a new key is
> pressed, 
> > ls will try the following:
> >  a) locate voices on that same key and release all but the last one
of
> them
> >  b) if that didn't yeld any results, go thru all keys and try same
> >  c) if that didn't work either, try same as above but be more
> aggressive 
> > i.e. free the last voice as well.
> > 
> > What do you guys think? Any better ideas?
> > I've been playing around with it and it seems to work OK. With max 
> > voices set to 64 i've set the threshold to 48 and it seems to take
> care 
> > of most situations. Depending on how long the release phase is, it
may
> 
> > need to be set to something lower (or max voices will have to be 
> > increased). At some point we could add a clever algorithm to
calculate
> 
> > the threshold automatically based on how long the release phase is 
> > (average release time for all samples?)
> > 
> > I'm including a patch against latest CVS. This patch also includes
> some 
> > command line and EG changes. Christian will likely review those (but
> not 
> > the voice stealing part) next weekend and it might make it in some
> shape 
> > of form into the CVS, so please give it some testing also, if you
have
> 
> > time. If you have trouble with voice stealing and just want to play 
> > around with the EG you can turn off voice stealing by setting 
> > AUDIO_VOICES_THRESHOLD to be same as MAX_AUDIO_VOICES in
> audiothread.h.
> > 
> > Regards,
> > Vladimir.
> > 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 

RE: [Linuxsampler-devel] voice stealing

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

On Sun, 2004-02-08 at 23:45, Peter E. Roos wrote:
> In any case the sustain pedal should bypass such an optimization  ;-)

Not if you're hitting the same note twice. There's no bypass happening
on that note in any case, whether pedal down or not.

> 
> I have read that GigaStudio has such an approach, but only when the
> velocity of the second note is louder than the first,

That might be an idea, suppose that the energy of the resonance which
has been dampened somehow carries over the next resonance thus it makes
the note sound louder. Still talking about the piano though,
well i'm not a physicist but anyway... :)

>  thus assuming it
> will mask the disappearance of the first note. 

Which instrument would need more than one voice per note?

Marek

> Otherwise, with some
> instrument, it may give a weird ending to the first note.
> 
> Peter Roos
> 
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...] On Behalf Of
> Marek Peteraj
> Sent: Monday, February 09, 2004 1:43
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] voice stealing
> 
> 
> Hi Vladimir & all,
> 
> just wanted to ask, is there any reason why linuxsampler can't have just
> one voice per note? For example suppose i've got a huge lib loaded with
> long samples that need to be streamed from disk,  currently AFAIK if i
> press a note and then press the same note again, i end up with 2
> streams. But if you imagine an instrument such as a piano, a hammer
> which hits a string at a given time is going to completely dampen the
> previous string resonance at that time while causing a new resonance.
> That seems like dismissing the old stream completely at the time i hit a
> note and starting a new one hence you end up with a nice 1 voice per
> note optimisation. Perhaps i'm wrong, just my imagination...
> 
> Marek
> 
> On Sun, 2004-02-08 at 19:50, Vladimir Senkov wrote:
> > Hi Everybody,
> > 
> > I've been thinking about note stealing or as i'd like to call it
> "voice 
> > stealing".
> > So far the following comes to mind:
> > 1) When number of voices reaches max there will not be any time to 
> > release them, so we have to start releasing them earlier. I'm 
> > introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain 
> > percentage of MAX_AUDIO_VOICES depending on how long the release phase
> 
> > is. If it's set to the same value as MAX_AUDIO_VOICES or higher, then 
> > voice stealing will be disabled.
> > 2) When number of voices reaches the threshold and a new key is
> pressed, 
> > ls will try the following:
> >  a) locate voices on that same key and release all but the last one of
> them
> >  b) if that didn't yeld any results, go thru all keys and try same
> >  c) if that didn't work either, try same as above but be more
> aggressive 
> > i.e. free the last voice as well.
> > 
> > What do you guys think? Any better ideas?
> > I've been playing around with it and it seems to work OK. With max 
> > voices set to 64 i've set the threshold to 48 and it seems to take
> care 
> > of most situations. Depending on how long the release phase is, it may
> 
> > need to be set to something lower (or max voices will have to be 
> > increased). At some point we could add a clever algorithm to calculate
> 
> > the threshold automatically based on how long the release phase is 
> > (average release time for all samples?)
> > 
> > I'm including a patch against latest CVS. This patch also includes
> some 
> > command line and EG changes. Christian will likely review those (but
> not 
> > the voice stealing part) next weekend and it might make it in some
> shape 
> > of form into the CVS, so please give it some testing also, if you have
> 
> > time. If you have trouble with voice stealing and just want to play 
> > around with the EG you can turn off voice stealing by setting 
> > AUDIO_VOICES_THRESHOLD to be same as MAX_AUDIO_VOICES in
> audiothread.h.
> > 
> > Regards,
> > Vladimir.
> > 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 

RE: [Linuxsampler-devel] voice stealing

[Peter E. R. <pet...@de...>]

In any case the sustain pedal should bypass such an optimization  ;-)

I have read that GigaStudio has such an approach, but only when the
velocity of the second note is louder than the first, thus assuming it
will mask the disappearance of the first note. Otherwise, with some
instrument, it may give a weird ending to the first note.

Peter Roos

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
Marek Peteraj
Sent: Monday, February 09, 2004 1:43
To: lin...@li...
Subject: Re: [Linuxsampler-devel] voice stealing


Hi Vladimir & all,

just wanted to ask, is there any reason why linuxsampler can't have just
one voice per note? For example suppose i've got a huge lib loaded with
long samples that need to be streamed from disk,  currently AFAIK if i
press a note and then press the same note again, i end up with 2
streams. But if you imagine an instrument such as a piano, a hammer
which hits a string at a given time is going to completely dampen the
previous string resonance at that time while causing a new resonance.
That seems like dismissing the old stream completely at the time i hit a
note and starting a new one hence you end up with a nice 1 voice per
note optimisation. Perhaps i'm wrong, just my imagination...

Marek

On Sun, 2004-02-08 at 19:50, Vladimir Senkov wrote:
> Hi Everybody,
> 
> I've been thinking about note stealing or as i'd like to call it
"voice 
> stealing".
> So far the following comes to mind:
> 1) When number of voices reaches max there will not be any time to 
> release them, so we have to start releasing them earlier. I'm 
> introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain 
> percentage of MAX_AUDIO_VOICES depending on how long the release phase

> is. If it's set to the same value as MAX_AUDIO_VOICES or higher, then 
> voice stealing will be disabled.
> 2) When number of voices reaches the threshold and a new key is
pressed, 
> ls will try the following:
>  a) locate voices on that same key and release all but the last one of
them
>  b) if that didn't yeld any results, go thru all keys and try same
>  c) if that didn't work either, try same as above but be more
aggressive 
> i.e. free the last voice as well.
> 
> What do you guys think? Any better ideas?
> I've been playing around with it and it seems to work OK. With max 
> voices set to 64 i've set the threshold to 48 and it seems to take
care 
> of most situations. Depending on how long the release phase is, it may

> need to be set to something lower (or max voices will have to be 
> increased). At some point we could add a clever algorithm to calculate

> the threshold automatically based on how long the release phase is 
> (average release time for all samples?)
> 
> I'm including a patch against latest CVS. This patch also includes
some 
> command line and EG changes. Christian will likely review those (but
not 
> the voice stealing part) next weekend and it might make it in some
shape 
> of form into the CVS, so please give it some testing also, if you have

> time. If you have trouble with voice stealing and just want to play 
> around with the EG you can turn off voice stealing by setting 
> AUDIO_VOICES_THRESHOLD to be same as MAX_AUDIO_VOICES in
audiothread.h.
> 
> Regards,
> Vladimir.
> 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] voice stealing

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

Hi Vladimir & all,

just wanted to ask, is there any reason why linuxsampler can't have just
one voice per note? For example suppose i've got a huge lib loaded with
long samples that need to be streamed from disk,  currently AFAIK if i
press a note and then press the same note again, i end up with 2
streams. But if you imagine an instrument such as a piano, a hammer
which hits a string at a given time is going to completely dampen the
previous string resonance at that time while causing a new resonance.
That seems like dismissing the old stream completely at the time i hit a
note and starting a new one hence you end up with a nice 1 voice per
note optimisation. Perhaps i'm wrong, just my imagination...

Marek

On Sun, 2004-02-08 at 19:50, Vladimir Senkov wrote:
> Hi Everybody,
> 
> I've been thinking about note stealing or as i'd like to call it "voice 
> stealing".
> So far the following comes to mind:
> 1) When number of voices reaches max there will not be any time to 
> release them, so we have to start releasing them earlier. I'm 
> introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain 
> percentage of MAX_AUDIO_VOICES depending on how long the release phase 
> is. If it's set to the same value as MAX_AUDIO_VOICES or higher, then 
> voice stealing will be disabled.
> 2) When number of voices reaches the threshold and a new key is pressed, 
> ls will try the following:
>  a) locate voices on that same key and release all but the last one of them
>  b) if that didn't yeld any results, go thru all keys and try same
>  c) if that didn't work either, try same as above but be more aggressive 
> i.e. free the last voice as well.
> 
> What do you guys think? Any better ideas?
> I've been playing around with it and it seems to work OK. With max 
> voices set to 64 i've set the threshold to 48 and it seems to take care 
> of most situations. Depending on how long the release phase is, it may 
> need to be set to something lower (or max voices will have to be 
> increased). At some point we could add a clever algorithm to calculate 
> the threshold automatically based on how long the release phase is 
> (average release time for all samples?)
> 
> I'm including a patch against latest CVS. This patch also includes some 
> command line and EG changes. Christian will likely review those (but not 
> the voice stealing part) next weekend and it might make it in some shape 
> of form into the CVS, so please give it some testing also, if you have 
> time. If you have trouble with voice stealing and just want to play 
> around with the EG you can turn off voice stealing by setting 
> AUDIO_VOICES_THRESHOLD to be same as MAX_AUDIO_VOICES in audiothread.h.
> 
> Regards,
> Vladimir.
> 

[Linuxsampler-devel] voice stealing

[Vladimir S. <ha...@so...>]

Hi Everybody,

I've been thinking about note stealing or as i'd like to call it "voice 
stealing".
So far the following comes to mind:
1) When number of voices reaches max there will not be any time to 
release them, so we have to start releasing them earlier. I'm 
introducing AUDIO_VOICES_THRESHOLD. It should be set to be a certain 
percentage of MAX_AUDIO_VOICES depending on how long the release phase 
is. If it's set to the same value as MAX_AUDIO_VOICES or higher, then 
voice stealing will be disabled.
2) When number of voices reaches the threshold and a new key is pressed, 
ls will try the following:
 a) locate voices on that same key and release all but the last one of them
 b) if that didn't yeld any results, go thru all keys and try same
 c) if that didn't work either, try same as above but be more aggressive 
i.e. free the last voice as well.

What do you guys think? Any better ideas?
I've been playing around with it and it seems to work OK. With max 
voices set to 64 i've set the threshold to 48 and it seems to take care 
of most situations. Depending on how long the release phase is, it may 
need to be set to something lower (or max voices will have to be 
increased). At some point we could add a clever algorithm to calculate 
the threshold automatically based on how long the release phase is 
(average release time for all samples?)

I'm including a patch against latest CVS. This patch also includes some 
command line and EG changes. Christian will likely review those (but not 
the voice stealing part) next weekend and it might make it in some shape 
of form into the CVS, so please give it some testing also, if you have 
time. If you have trouble with voice stealing and just want to play 
around with the EG you can turn off voice stealing by setting 
AUDIO_VOICES_THRESHOLD to be same as MAX_AUDIO_VOICES in audiothread.h.

Regards,
Vladimir.

[Linuxsampler-devel] LS talk at the LAD Conference in Karlsruhe/Germany

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

The ZKM folks that organize
 the 2nd Linux Audio Developers Conference 29 April - 2 May 2004
in Karlsruhe/Germany

http://www.zkm.de/lad/
here are the list of proposed talks:
http://on1.zkm.de/zkm/stories/storyReader$3624


asked if we want to give a talk about LinuxSampler.
Who of the LinuxSampler team is planning to attend the 
Linux Audio meeting ?
Steve H. yes,  Christian S. , others ?
Christian would you like to give the talk or do we want
to do some joint talk (which I think is probably better so you
can talk about libgig and other high-tech stuff you've done :-) ).


The abstract of the talks must be sent to Matthias Nagorni next
week so I'd like to ask you guys what to put in it.

some proposals:

- LS history 
- Goals, long/short term
- current status
- interoperability with other OSes (VST, native Mac version etc)
- sample formats (libgig, akai etc)
- collaboration with companies (like sample library developers, 
hardware manufacturers like Lionstracs etc).

- pratical LS demonstration on a Laptop

please make comments, add items to put on the list, 
add some food of thought etc :)

BTW for those not familiar with the Linux Audio Developer Meeting:
it is open (free entry) to all both developers, general public, companies
working in the audio/midi field, journalists etc.

So if you have the possibility to make it there it will pay off because
it will be an interesting event for anyone interested in the linux audio
 field.


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








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

Re: [Linuxsampler-devel] new to the list, PMI

[Michiel P. <mp...@xs...>]

Hi both,

Thanks for the warm welcome. I'm looking forward working with LS.=20
Benno, your remarks regarding the low prices of LS-capable hardware is =
actually a very strong argument. Let's see how the LS performs and how =
it sounds.=20
Copyprotection will have to wait untill we are ready to release things =
in a generic LS format. I understand the feelings there are related to =
this topic. I understand very well there are two sides to CP (every =
effort to get protection is a waste of time and recources since every =
protection method will be cracked, even more so in an open source =
platform and on the other hand new methods to make money using the extra =
benefits of open source platforms will have to be found, securing income =
and fascilitating global penetration of LS). In the mean time I will =
research watermarking solutions. If anybody has a clue where to search =
you're most welcome to send me a link.
GigaStudio 3 is near it's release. I worked with it during my Los =
Angeles visit and had the pleasure to join the TASCAM developers =
breakfast meeeting where the latest features were shown. Let me give a =
short impression of the latest features.=20
- new drivers were developed that enable bi-directional use of the =
soundcard to and from GST3. You can record samples (8 channels) straight =
into GST and playback (up to 16 channels) at the same time. This is =
needed because the GST mixer now accepts VST plug-ins. So integration =
with Re-Wire and with live input streams makes it possible to mix all =
sources in GST3.=20
- VST support; important feauture. VST plug-ins are a huge succes. =
Partly because there are a lot of free and very good ones on the market. =
For example SIR (a real-time convolution engine) offers better IR-based =
reverb than any commercial artificial reverb unit. And it's free. =
Latency is a problem still but that will change over time. With VST =
support your sampler becomes a more flexible machine since you can =
insert the plug-in at the source.
- GST has 8 midi ports, each with 16 midi channels (or slots). Each slot =
can load multiple gig files. So the total number of available slots =
(with unique midi channel inputs) is raised to 128, but the total number =
of loaded gig files can be much higher. Actually each slot can load up =
to 256 files or instruments from a file.=20
- sample compression; there is a new compression algoritme used. It can =
(off-line) render 24 bit wav files to 24 float, integer, 22 or 20 bit =
and 16 bits with a 66% smaller file size. So a 24 bit file is lossless =
compressed to the same size as a 16 bits file. What is more important, =
the data transfer load on the system bus is also 33% lower. Streaming 24 =
bits compressed samples takes up the same data bandwidth as 16 bit =
samples. Hence polyphony will be much higher.=20
- The gig structure has been changed: it now has intelligent midi. This =
means that apart from the increased number of dimensions there is also a =
midi data matrix (decision maker). For example: if a midi controller =
changes status (like the sustain pedal) you can use it to trigger a note =
on command. Or you can make a legato tool like used in VSL and Maestro =
tools. Or you can make an automated up-down stroke alternator. Or =
phrases; short-short-long (1-1-2), Long-long-short-short (2-2-1-1). =
Where different articulations are used.=20
- The UI is really a lot better now. One of the most striking new things =
is the new mixer layout and quick edit feature for gig files. From the =
main application you have quick access to the most common used =
parameters (ADSR's, Filter controls, you can see the Wav file, the loops =
for each wav file, the micro tuning etc etc). All edits are visible in =
the interface (change the Attack, see it in the wave graph).
The number of changes in the gig structure is too big to discuss here =
without possibly disclosing confidential info. I will be back with more =
details here.

fxteleport
There is a new utility that enables you to run a slave machine without =
audiohardware. The idea is that all midi and audio (in and out) is =
carried over the LAN connection. This way you can save a lot on =
hardware. The app. installs on multiple machines in a network. On the =
host machine, where the sequencer is running, there's a VST wrapper.  =
You will see a new VST folder named "FX Teleport" with all the familiar =
plug-ins, but with (LAN) extensions. You can use those FX in the usual =
way you work with VST plug-ins. When such an effect is used, the VST =
wrapper launches and searches for FX Teleport server applications on the =
network, and on finding those starts the chosen effect on the remote =
machine. Next the VST wrapper serves as a bridge between the host and =
the remote machine. It flows the stream to the effect and processed =
signal back to the host machine. www.fxteleport.com  If this could =
extend to Linux boxes too or if a similar app could be made for Linux...



> _______________________________________________
> Linuxsampler-devel mailing list
>=20
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 30-1-2004

RE: [Linuxsampler-devel] new to the list, PMI

[Vladimir S. <ha...@so...>]

Benno,

>Running Linux and Windows in parallel on the same machine is possibile
but is fleasible only for applications that do not need real time
response, like Office applications etc. But for LS it would be
impossible to run it in a Linux-emulation window under Windows (using an
application like VMWare wich allows running multiple OSes at the same
time). The real time response and disk streaming performance would
simply suck due to the added overhead of emulation layer.

Yes, but what about the other way around . . .
Running windows in VMWARE on linux host. LS runs on the host. Sequencer
runs in windows.
I think that could work OK in some configurations.

>Regarding copyprotection: is it a task to solve and dongles are not the
ideal solution since the software will probably be cracked after some
time. I mostly agree with what Bruce A.R. said on the NS forums that
individual watermarking is probably the most flexible solution. At least
is helps to identify who posted the sample CD on the net and will deter
people form posting copies of their stuff on P2P apps or websites.

Individual watermarking is probably a big pain in the butt for sampler
producers, but I think it's the only way to go. Software will not even
have to be cracked if it's opensource. Someone could just convert LS
into a "sampler converter utility".

Regards,
Vladimir.

Re: [Linuxsampler-devel] new to the list, PMI

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

Hi Michiel,
thanks for joining the list,
your feedback will be very valuable because we know of your high quality
standards when producing sample libraries which means you will be valuable
for spotting playback imperfections (eg wrong velocity mappings, etc)
in LS and of course giving advices and ideas for new development directions.

About installing Linux, as said I'll write a small document on our website that
explains in short how to set Planet CCRMA  which add on packages
for Red Hat Linux that turn it in linux distribution optimized for music, alias
kernel optimized for low latency (better real time response), audio drivers for
the high end audio cards (ALSA drivers) installs
an easy to use package management that permits the one click install of
precompiled music apps and system libraries etc.


Michiel, your P4 1.8 is fully Ok for LS testing, I perform some tests
on much slower boxes (Celeron 400, VIA 1GHz) and the performance is quite
good there. Testing on slower boxes makes it easier to spot performance problems
and helps to make the engine very fast.
Your P4 is pretty high end and depending from your HD it allows easily
for 120-150 stereo voices (or hundred of mono voices).
So it is fully ok for testing.
Regarding hollywood composers, well at first it was a bit of a half joke between
us developers, in the sense we want to satisfy even their professional needs,
wich means if we can satisfy them we can satisfy anyone.
Of course before LS is ready for Hollywood it must provide perfect GIG playback
and network clustering with VSTi frontends. So it will still take some time.
As you said our main target is probably the average (relatively poor) windows
users which want to have a powerful sampler at his disposal.

Of course there windows users are using their own windows sequencers and
don't want do give them up easily since these apps under Linux are not
so mature like under Windows yet.
So a good compromise is to use a second box with LS with a VSti/AudioUnit
frontend which permits working with LS as it was a local application.

I mean: exclude those that pirate a soft sampler for windows/mac.
The cost of such a sampler is usually $300-$500. With that amount of money
you can buy a quite powerful machine these days and dedicate it entirely to
sampling.
So LS provides more much performance for the money, since if you are running
a windows softsampler on the same box that runs the sequencers, the performance
 (and possibility to load large sample setups) will not be as high as when
using two machines.

Running Linux and Windows in parallel on the same machine is possibile but
is fleasible only for applications that do not need real time response,
like Office applications etc.
But for LS it would be impossible to run it in a Linux-emulation window under
Windows (using
an application like VMWare wich allows running multiple OSes at the same time).
The real time response and disk streaming performance would simply suck due
to the added overhead of emulation layer.

About porting LS to other operating systems.
This would be ideal for getting a big marketshare quickly.
For example since OS X is based on UNIX and the LS codebase is quite portable
it would probably be quite easy to produce a native OS X version with
a VSTi or AudioUnit interface.
Probably we will do the port as soon as full GIG support in LS is completed
and as soon as the GUI is finished.
We use the Qt GUI programming library which permits to port the GUI code
to multiple OSes (Linux,Mac, Windows and others) by simple recompilation.

So don't worry, as soon as the first public LS version is a native
OS X version (which will provide high performance too since OS X is optimized
for audio) will
 be produced too.
This will bring new developers, new ideas and other useful stuff that
will benefit the entire LS project (thus Linux users too).

Now to Windows:
would a Windows port of LS be possible.
Definitively. The LS audio engine is small and portable because you mostly
need only to add a new audio output method and midi input method to make it work.
The GUI (when ready, Rui is working on it) is in Qt too so it can be compiled
on Windows without modification.
So while a local VSTi on Windows is possible it would be plagued by the same
problems that afflict other plugs: it's hard to get latency
down while maintain dropout-free operation, streaming performance is usually
 lower than on Linux etc.
Anyway at least for me (I'm speaking when LS on Linux will work well) I'm
not against a native Mac/Win port.
Of course our wish would be all users switching to Linux but on a short-term
basis this is simply not going to happen.
So any new user/developer of LS would benefit the project, regardless of
the operating system they use.
(just like OpenOffice profits from Linux, Solaris, Windows and Mac users).

Of course for a Mac/Windows port we would need the help of experienced
developers but I think once they see the potential of LS they will join us.
For example, ardour a prootols-like audio sequencer for Linux (
http://ardour.sourceforge.net ) is achieving professional grade level and
people are interested to have an OS X port. Work is underway and it will not
be that hard since ardour's code is quite portable.
Once many Mac users will use ardour it will benefit Linux ardour users too.

We need to set small goals, one after one.
For now the first goal is to get perfect GIG playback and an easy to use
 GUI working so that people can use LS in production enviroments, or
can be used on dedicated LS "expanders" wich can run PMI's and other libraries
out of the box, without needing configuration etc.

Then after this step many things can be done, like
an open/flexible sampling format to accomodate sample producers
special needs, sampling engines which tune themselves to get high
performance out of low cost hardware etc.

Regarding copyprotection: is it a task to solve and dongles are not
the ideal solution since the software will probably be cracked after
some time.
I mostly agree with what Bruce A.R. said on the NS forums that individual
watermarking is probably the most flexible solution.
At least is helps to identify who posted the sample CD on the net and
will deter people form posting copies of their stuff on P2P apps or websites.

Anyway let's worry about this stuff after the initial LS version is finished,
bfore that it does not make sense since no one is going to use our sampler
if it does not sound well :-)

Comments and questions welcome.

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

Scrive Michiel Post <mp...@xs...>:

> Hi LS group, 
> 
> I´m new to this group so let me introduce myself to you guys.
> 


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

Re: [Linuxsampler-devel] more commandline options

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

On Sun, 2004-02-01 at 21:24, Vladimir Senkov wrote:
> Mark,
> 
> Here is a patch for command line options.
> Now, you can specify alsa card or jack playback channels or both.
> If your LS is built without jack support jack options will be ignored.
> If you do have jack support and you do not specify any playback channels 
> it will not connect automatically and you will have to do it manually.
> If you specify channels it will try if it fails you can still connect 
> manually.
> If jack is not running it will fall back to alsa and will try to use 
> either specified card or default (0,0).
> If card is specified but jack channels are not, jack will not be 
> connected to even if it is running.
> 
> Please let me know if there are any problems.
> BTW, with jack i can not get my LS to work correctly. It sounds out of 
> tune . . .
> Without jack everything works good. Have you had any similar problems?
> 
> Regards,
> Vladimir.

Wow! Sounds great Vladimir. Unfortunately we did not get sound back on
my RME card. The driver now installs but the card gives no status and so
the mixer won't start. Since Thomas is in Berlin we're done for the day
and back at it as he finds time. I hope it's soon. I'm anxious to play
with all the stuff you've worked on.

Cheers,
Mark