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

Re: [Linuxsampler-devel] Win32-Integration-Proposal

[Mattias H. <ma...@mu...>]

"Instead" would make us Sonar users unhappy due to the underwhelming ReWire
integration... "Also" is more like it. Of course, once you do one or both of
these, plenty of users will scream "how about a proper DXi
implementation"... :-)

/Mattias

> Instead of VST, or in addition to VST, how about ReWire? I'm not a user
> of either of these, but I think ASIO and VST will leave out Pro Tools
> (my platform) while ReWire is supported.

RE: [Linuxsampler-devel] Win32-Integration-Proposal

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

On Sat, 2004-01-10 at 03:40, be...@ga... wrote:

> Regarding ASIO:
> I'm not sure if ASIO is the way to go, how about going directly VST ?
> VST is supported by any professional application under Windows plus
> it has builtin MIDI which means you don't need to write a MIDI driver
> the plugin directly gets the MIDI events from the sequencer.
> Plus the VST callback is called exactly ( process() ) for each audio
>  fragment processed, wich makes the whole stuff even more simple.
> 
> Comments ?

Instead of VST, or in addition to VST, how about ReWire? I'm not a user
of either of these, but I think ASIO and VST will leave out Pro Tools
(my platform) while ReWire is supported.

Re: [Linuxsampler-devel] Win32-Integration-Proposal

[Mattias H. <ma...@mu...>]

Hi,

I'm new here... I became interested in this project after Benno's post on
the NorthernSounds forum (I didn't know about LS before that). I'm not a
Linux user today, but I'm developing Windows software for a living and I'm
running a pretty well equipped and fully booked studio the rest of my
time... Anyway, I'm always interested in new solutions and this seemed to be
interesting. I'll lurk on this list and maybe chime in when I have something
to add. Since my Linux specific knowledge is near zero right now my
contribution will mostly be in the idea/usage department.

> I'm not sure if ASIO is the way to go, how about going directly VST ?
> VST is supported by any professional application under Windows plus
> it has builtin MIDI which means you don't need to write a MIDI driver
> the plugin directly gets the MIDI events from the sequencer.
> Plus the VST callback is called exactly ( process() ) for each audio
>  fragment processed, wich makes the whole stuff even more simple.

This is exactly what I was about to suggest yesterday. From a user
perspective this is much more usable than some midi driver + audio driver
solution. I'm using FXTeleport on the Windows platform today and this is
exactly how it works. I don't know what you think about this but why not
integrate this solution with FXT? FXT already have the Win32 parts ready,
stable and working. What would be needed to accomplish this is:

* A "server" client that lives on the Linux server that connects to the FXT
host on the sequencer machine.
* A VSTi that controls LS from the Win32 machine, sends midi to, and
receives audio from LS. Maybe this VSTi could even incorporate a Windows
based remote control for LS.

This idea is of course depending on whether Max, the developer of FXT, is
willing to open up he communicaton specs he's using... I actually wrote him
a mail yesterday with the idea as I've been working with him quite closely
with a couple of things lately. I'll let you know whether this would be at
all possible when I hear from him.

/Mattias

RE: [Linuxsampler-devel] Win32-Integration-Proposal

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

Isn't it possible to change the From address to "Linux-Sampler" in the mails
from the listserver?
I nearly made the same mistake in my first post :-)


-----Original Message-----
From: be...@ga... [mailto:be...@ga...] 
Sent: Saturday, January 10, 2004 12:41
To: lin...@li...
Subject: RE: [Linuxsampler-devel] Win32-Integration-Proposal


Tobias you did reply only to me privately (by accident) so I'm forwarding 
it to the list.
List members, please when replying only reply to the list,
CCs to members that are on list are useless and will result in annoying 
duplicate mails :-)

RE: [Linuxsampler-devel] Win32-Integration-Proposal

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

Forgive me for going slightly OT, but:
Gigabit ethernet of course has a much higher bandwidth than 100 mbit, but I
once read a post from Matthias Carsten from RME who stated that gigabit puts
a rather high load on the CPU due to increased interrupt handling and (I
think) he said it had a bad effect on the performance of audio cards.

Can anyone comment on this?
TIA,

Peter Roos
Netherlands

-----Original Message-----
From: be...@ga... [mailto:be...@ga...] 
Sent: Saturday, January 10, 2004 12:48
To: Linux-Sampler
Subject: Re: [Linuxsampler-devel] Win32-Integration-Proposal


While 1394 is nice and gives some real time guarantees it has 
the drawback that it's harder to buy long cables, switches build 
large networks etc. I guess such setups are much more expensive.

If you dedicate ethernet to audio it is very reliable and except in
some troublesome cases the packet loss ratio and high latencies are 
basically zero.
Even with a cheap D-Link 8 port switch I achieve the full 100Mbit
and constant 0.1-0.2 msec ping times between two linux boxes.
The poor man's linuxsampler cluster is much more likely to use
ethernet than firewire since it has a lower TCO.
That said firewire will be handy too but for now let's put the main
weight on ethernet.

Indeed, 2004 will become an interesting sampling-year :-)

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

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

> On Fri, 2004-01-09 at 15:17, Christian Schoenebeck wrote:
> > I think a JACK client that implements the network protocol would be a
> better 
> > idea. 
> 
> There is a new Jack client written by Bob Ham for doing Jack over 1394
> also. I haven't had a chance to test it, but with more bandwidth and
> guaranteed delivery times 1394 could offer something here also. It would
> be nice to actually send MIDI requests to LS and be able to return audio
> over the same cable in a very deterministic way.
> 
> Anyway, fun to think about...
> 
> Cheers,
> Mark
> 


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


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Win32-Integration-Proposal

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

While 1394 is nice and gives some real time guarantees it has 
the drawback that it's harder to buy long cables, switches build 
large networks etc. I guess such setups are much more expensive.

If you dedicate ethernet to audio it is very reliable and except in
some troublesome cases the packet loss ratio and high latencies are 
basically zero.
Even with a cheap D-Link 8 port switch I achieve the full 100Mbit
and constant 0.1-0.2 msec ping times between two linux boxes.
The poor man's linuxsampler cluster is much more likely to use
ethernet than firewire since it has a lower TCO.
That said firewire will be handy too but for now let's put the main
weight on ethernet.

Indeed, 2004 will become an interesting sampling-year :-)

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

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

> On Fri, 2004-01-09 at 15:17, Christian Schoenebeck wrote:
> > I think a JACK client that implements the network protocol would be a
> better 
> > idea. 
> 
> There is a new Jack client written by Bob Ham for doing Jack over 1394
> also. I haven't had a chance to test it, but with more bandwidth and
> guaranteed delivery times 1394 could offer something here also. It would
> be nice to actually send MIDI requests to LS and be able to return audio
> over the same cable in a very deterministic way.
> 
> Anyway, fun to think about...
> 
> Cheers,
> Mark
> 


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

RE: [Linuxsampler-devel] Win32-Integration-Proposal

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

Tobias you did reply only to me privately (by accident) so I'm forwarding 
it to the list.
List members, please when replying only reply to the list,
CCs to members that are on list are useless and will result in annoying 
duplicate mails :-)

Anyway a few thoughts:

since we face the MIDI over ethernet problem too.
Why not do both in one rush ?
I propose the following: since the windows box must send
the sync packet to wake up LS. That sync packet could contain the midi data
The bandwidth of a MIDI channel is usually 31250kbit/sec
which is about 3000bytes/sec, quite low for an ethernet network.
So assume we use 128 sample fragments. (but make it configurable of course)
at 44100Hz this means 44100/128 = 344 packets per second sent by LS to
the windows box and 344 sync packets sent from the windows box to LS.
The sync packet carries no payload and we can use it to transmit midi data.
So I'd say define a maximum number of MIDI bytes per sync packet value.
Eg 128. This means 128*344 a virtual midi channel with a bandwidth of 44KB/sec.
Which is ten times as high as standard MIDI.

So on the windows box we need to write a small midi driver that listens
to local midi events and puts them into the outgoing sync packet queue.
In the rare case where we achieve the maximum midi bytes per sync packet
 value, we can send the rest of the MIDI bytes with the next sync packet.
LS will simply parse the incoming midi bytes that came with the sync packet
and if there are incomplete MIDI messages (eg only the note on byte and
 pitch value but the velocity byte has not been transmitted yet), it will
simply let it sit in a local queue/fifo and parse it at the next cycle.
Its very simple.

Regarding ASIO:
I'm not sure if ASIO is the way to go, how about going directly VST ?
VST is supported by any professional application under Windows plus
it has builtin MIDI which means you don't need to write a MIDI driver
the plugin directly gets the MIDI events from the sequencer.
Plus the VST callback is called exactly ( process() ) for each audio
 fragment processed, wich makes the whole stuff even more simple.

Comments ?

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



Scrive Tobias Erichsen <t.e...@gm...>:

> 
> 
> > -----Original Message-----
> > From: lin...@li...
> > [mailto:lin...@li...]On Behalf Of
> > be...@ga...
> > Sent: Friday, January 09, 2004 11:13 PM
> > To: lin...@li...
> > Subject: Re: [Linuxsampler-devel] Win32-Integration-Proposal
> > 
> > 
> > Excellent Tobias !
> > That's exactly what future professional studio users will need.
> > That you already wrote an ASIO driver is very very valuable.
> > 
> > I'd opt for UDP for the transmission protocol.
> 
> I want to send the stuff using RTP which is based on UDP
> and is specifically used for audio & video transmission
> stuff...
> 
> > (without retransmission since in local networks
> > the packet loss ratio is basically zero, and retransmission would kill
> > latency).
> 
> That's right - at work we are doing Voip-stuff, which for the
> same reasons is using UDP/RTP because retransmissions are
> bad for realtime-data...
> 
> I thought that I would synchronize the stuff to the clock
> of the PC-soundcard, as obviously this is the one driving
> the sequencer as well... so whenever the soundcard on the
> pc finishes a block of audio-data, i will send a packet
> to the other side... which then would cause ls to send
> a new packet...
>  
> Tobias 
> 




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

Re: [Linuxsampler-devel] Win32-Integration-Proposal

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

On Fri, 2004-01-09 at 15:17, Christian Schoenebeck wrote:
> I think a JACK client that implements the network protocol would be a better 
> idea. 

There is a new Jack client written by Bob Ham for doing Jack over 1394
also. I haven't had a chance to test it, but with more bandwidth and
guaranteed delivery times 1394 could offer something here also. It would
be nice to actually send MIDI requests to LS and be able to return audio
over the same cable in a very deterministic way.

Anyway, fun to think about...

Cheers,
Mark

Re: [Linuxsampler-devel] Win32-Integration-Proposal

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

Es geschah am Freitag, 9. Januar 2004 23:12 als be...@ga... schrieb:
> Windows box (ASIO driver) {
>
>   send_sync_packet_to_linuxsampler_box();
>   wait_for_audio_packet_from_linuxsampler_box();
>   write received data to ASIO buffer
> }

Multi threaded of course and buffered stream

> > Tobias
> >
> > PS.:
> > Obviously there would be the need to implement a
> > virtual soundcard for ALSA as well - but perhaps
> > someone already developed such a beast ;-)

I think a JACK client that implements the network protocol would be a better 
idea. And btw. MIDI over ethernet is also planned for LS and there's already 
a standard IEEE network protocol defined. The problem for Windows side is 
that there's only one free client so far - DMIDI - and that has only support 
for receiving, not for sending MIDI messages so far AFAIK. Or has that 
changed meanwhile? Could you also imagine to extend that client? I guess this 
would be welcome by many Windows users. The DMIDI client registers just as a 
normal MIDI port on the Windows system, you can select IP and port address 
with a graphical configuration frontend and you would be able to use a rack 
of LinuxSampler boxes and access them in e.g. in Cubase as they would be 
normal MIDI devices.

I'm of course also looking forward to your results!

CU
Christian

Re: [Linuxsampler-devel] Initial Envelope Generator

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

Scrive Christian Schoenebeck <chr...@ep...>:

> Hi everybody!
> 
> Sorry that I didn't had time to answer. I'm currently implementing EG1 
> (amplitude envelope generator), so no need for a quick hack, I hope to finish
> 
> it tomorrow or at least til sunday.
> 

Wow Christian, that would be wonderful ! (friday is the D-Day)
I'll tell the sampling producers to handsign you a copy of their sampling CDs,
but only if their CDs play back well on LS :-)


> 
> end (usually the limit of the variable type), and the other two are 
> self-explanatory I think. This heavy function is not a problem because it 
> will only be calculated once when a voice will be triggered (or sustain value
> 
> changed by some controller, etc.).

Yes if this happens only at note trigger time then it's fully ok.

> 
> I'm not sure already, but at the moment I'm more tending to queue and process
> 
> events sample accurate not only in a certain amount of steps (32 was proposed
> 
> by Steve I think). My idea is to use two different Interpolate loops; one 
> which processes events and one that is executed when there are no events 
> queued for the current time stage. This will switch respectively.

you mean like I said the other day ?

render_audio() {

  while(samples_left) {
  samples_to_next_event=s2=check_for_events();
// if no events are pending samples_to_next_event should be
  samples_left

  while(--samples_to_next_event) {
   interpolate();
  }
  samples_left -= s2;
}

David O. is this ok ?
More efficient methods ?

cheers,
Benno



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

Re: [Linuxsampler-devel] Win32-Integration-Proposal

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

Excellent Tobias !
That's exactly what future professional studio users will need.
That you already wrote an ASIO driver is very very valuable.

I'd opt for UDP for the transmission protocol.
(without retransmission since in local networks
the packet loss ratio is basically zero, and retransmission would kill
latency).
Ok perhaps for offline track bouncing using a TCP socket
would be handy (for the paranoid that fears to loose one packet
out of 10million packets transmitted).
But for now I think UDP is the way to go.
Regarding synchronizing with the windows machine.
The AudioIO class in LinuxSampler contains code to output audio,
in the network case instead of outputting audio you send out an
UDP packet that contains as much data as you would send to the soundcard.
But there is a problem: in the case of audio the soundcard blocks while
in the case of using the UDP sending routine the packet gets out immediately
and we need LinuxSampler wait for the windows box acknowledging the packet
since we must send out at a rate which matches the samplerate of the
windows soundcard.
I think the easiest to way to achieve synchronization is:

LinuxSampler:

writeAudio(data) {
  wait_for_sync_packet_from_windows_box();
  send_audio_packet_to_windows_box(data);
}

Windows box (ASIO driver) {

  send_sync_packet_to_linuxsampler_box();
  wait_for_audio_packet_from_linuxsampler_box();
  write received data to ASIO buffer
}

The sync packet is very short and does not need to carry a special payload.
It's just to "wake up" LinuxSampler.

Perhaps on the windows receiving end we need to buffer more than one 
packet to avoid audio dropouts. Please make this configurable
on the Windows side.
But on the linuxsampler sending side no buffering is needed, one packet is fully
ok, just listen for MIDI-in events, process audio and send out UDP packet.

Just start experiment with it by modifying the AudioIO, I'm sure
you will come up with interesting results !

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






Scrive Tobias Erichsen <t.e...@gm...>:

> Hi guys,
> 
> I've followed the project for a couple of month now
> and I was always interested in doing some work for
> this.  I think someone mentioned that one of the
> goals of LS was the idea of having a rack of Linux-
> based samplers running and use them from remote
> by their favorite sequencer-program.
> 
> I thought this was a pretty cool idea and would like
> to offer to implement some kind of Win32-support for
> this.
> 
> My idea is the following:
> 
> I have already written a generic ASIO-driver for the
> Windows-Plattform (www.asio2ks.de) and I thought about
> including some network-streaming-code, so this asio-driver
> would have the "real" audio-ports from underlying
> soundcard and have "virtual" ports which are fed over
> IP/UDP/RTP from LS. I think the local network should
> provide for low enough latency for this...
> 
> So if you have a sequencer like Cubase, you would define
> the "virtual" ports as inputs into the cubase-mixer and
> the "real" ports as output for monitoring to the monitor-
> boxes...
> 
> What do you guys think about this?
> 
> Tobias
> 
> PS.:
> Obviously there would be the need to implement a
> virtual soundcard for ALSA as well - but perhaps
> someone already developed such a beast ;-)
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




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

[Linuxsampler-devel] Initial Envelope Generator

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

Hi everybody!

Sorry that I didn't had time to answer. I'm currently implementing EG1 
(amplitude envelope generator), so no need for a quick hack, I hope to finish 
it tomorrow or at least til sunday.

First the EG will be just be a simple ASR one (with Attack=lin and 
Sustain=exp). Extending that later to PADSDR (as used in Gigasaampler) is 
very trivial.

I will calculate the exponential curve by this simple discretisation of the 
exp() function:

	env = 1.0
	loop {
		env  =  env - env * release_coeff
		fire_vca_event(env);
	}

this will be done before the interpolate loop, within the EG class. It just 
fires it's VCA events and then in the Interpolate loop I just add the delta 
value of the VCA event.

The release_coeff is calculated in this way:

	release_coeff = 1 - exp(ln(limit)/release_ms*samplerate*0.001)

where 'limit' is the bottom value limit of the exp curve considered to be the 
end (usually the limit of the variable type), and the other two are 
self-explanatory I think. This heavy function is not a problem because it 
will only be calculated once when a voice will be triggered (or sustain value 
changed by some controller, etc.).

I'm not sure already, but at the moment I'm more tending to queue and process 
events sample accurate not only in a certain amount of steps (32 was proposed 
by Steve I think). My idea is to use two different Interpolate loops; one 
which processes events and one that is executed when there are no events 
queued for the current time stage. This will switch respectively.

Any doubts?

CU
Christian

[Linuxsampler-devel] Win32-Integration-Proposal

[Tobias E. <t.e...@gm...>]

Hi guys,

I've followed the project for a couple of month now
and I was always interested in doing some work for
this.  I think someone mentioned that one of the
goals of LS was the idea of having a rack of Linux-
based samplers running and use them from remote
by their favorite sequencer-program.

I thought this was a pretty cool idea and would like
to offer to implement some kind of Win32-support for
this.

My idea is the following:

I have already written a generic ASIO-driver for the
Windows-Plattform (www.asio2ks.de) and I thought about
including some network-streaming-code, so this asio-driver
would have the "real" audio-ports from underlying
soundcard and have "virtual" ports which are fed over
IP/UDP/RTP from LS. I think the local network should
provide for low enough latency for this...

So if you have a sequencer like Cubase, you would define
the "virtual" ports as inputs into the cubase-mixer and
the "real" ports as output for monitoring to the monitor-
boxes...

What do you guys think about this?

Tobias

PS.:
Obviously there would be the need to implement a
virtual soundcard for ALSA as well - but perhaps
someone already developed such a beast ;-)

RE: [Linuxsampler-devel] Sample Library producers meet LinuxSampler at NAMM :-), was: Release samples, sustain quick release

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

Benno,

I should have time this weekend to work on a (better) hack. I need to
figure out what to do with the remainder of the
AudiThread::ReleaseVoice(). If Christian had time too that'd be awesome
because I really understand very little about ls architecture yet.
For now I just call Release() there but there is some sustain handling
there I need to figure out how to do. If I leave it there now there as
is it cores on the next attack if I take it out completely it seems to
work but there is usually something wrong with taking something you
don't understand completely out so I need to learn and understand it
first . . .
But I must point out that sustain seems to work still (somehow).
For a hack solution, Jan15 doesn't sound that bad, but it will probably
remain mostly untested.
Too bad I'm not in California otherwise I'd check it out . . .
I'm glad you are getting lots of positive responses on namm forum!

Regards,
Vladimir.

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
be...@ga...
Sent: Thursday, January 08, 2004 5:21 AM
To: lin...@li...
Subject: [Linuxsampler-devel] Sample Library producers meet LinuxSampler
at NAMM :-), was: Release samples, sustain quick release


Great Vladimir !

I'm heading to NAMM ( http://www.thenammshow.com/ ) with
a company that produces Linux based musical instruments (
http://www.lionstracs.com ).

I asked on northernsounds.com (a forum frequented by sample library
producers, hollywood composers etc :-) ), if anyone wants to see
LinuxSampler in action and that we seek collaboration with sample
library producers and the response was very positive.

see my post here:
http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php?ubb=get_topic;f=
3;t=006841;p=1

For now about 3-4 well known sample library producers have agreed to
speak with  us. That's very nice, they see the big potential of LS.


But for the NAMM (begins January, 15) it would be cool if someone could
produce a quick "hack" like Vladimir did to add simple a release
envelope to get rid of clicks at note-offs. That way we make a much
better impression when the sample producer guys will listen at it.
Unfortunately I have no time to lend you a hand because this weeek is
very stressful so it would be cool if Vladimir together with Christian
and others could produce this quick "release envelope hack" to show off
at NAMM. (the important thing is that it should not crash when you
press/release sustain)


I count on you guys ! (let me know here on the mailing list if you
produce a patch for that date).

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



Scrive Vladimir Senkov <ha...@so...>:

> 
> Anyway, long story short the only thing that i didn't enjoy about 
> linux sampler was that clicking noise that results from no release 
> sample support, so i've decided to try to do something about it.


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


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linuxsampler-devel mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

RE: [Linuxsampler-devel] Release samples, sustain quick release

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

Benno,

Most of those samples are in SF2 format, but not all. There is one
pretty good 35M .gig sample there.
That's the one I have been using . . .
Good news about free samples from NAMM! How do we get them? :)

Regards,
Vladimir.

PS: I'm pretty sure there was an "unrar" utility for linux, but I
haven't used it with self extracting archives.
I can probably ask the author for permission to redistribute his .gig
(or maybe he could put it out there in .gz instead of rar self extractor
for us linux users, I'm sure he'll be excited to know that he can use
linux sampler with his own sample too :)

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
be...@ga...
Sent: Thursday, January 08, 2004 5:45 AM
To: lin...@li...
Subject: Re: [Linuxsampler-devel] Release samples, sustain quick release


the sfArk decompression utility (for Windows) works without any problem
under Linux using Wine. download the sample in .sfark format. download
SfArk from http://www.melodymachine.com/sfark.htm
wine sfark_setup.exe
and then use the application's filedialog to load and decompress the
file. easier than that ? :-) Anyway those samples are in SF2 format so
for now of little use for LinuxSampler.

BTW in my post about the Sample Library producers
I forgot to say that those that will come at NAMM 
agreed to give us a few free sampling CDs that LinuxSampler developers
can use for development and testing purposes. Very nice !

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

Scrive Mark Constable <ma...@re...>:

> > > http://www.musik.auc.dk/~bovbjerg/piano4.html
> 
> Glug. Sorry to be boring but would anyone have a plain
> uncompressed linux-friendly version of any of these files
> available online somewhere, particluarly the gig ?
> 
> --markc
> 
> 


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


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linuxsampler-devel mailing list Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Sample Library producers meet LinuxSampler at NAMM :-), was: Release samples, sustain quick release

[David O. <da...@ol...>]

On Thursday 08 January 2004 12.23, David Olofson wrote:
[...Audiality EG...]
> I'll go have a look at the code...

Well, there are some issues:

=09* It doesn't handle volume changes during sections,
=09  so you can't fade while playing a note. (Not an
=09  issue if volume is handled elsewhere in the signal
=09  chain, though.)

=09* Sustain->release is a one-way state change. No
=09  sustain double clutching, that is.

=09* And it's a DAHDSR, of course... Generic N-section
=09  envelopes are much more flexible.


This is stuff I'll need to fix eventually anyway. The envelope should=20
have a "gain" input that supports ramp events, for "live" volume=20
control. (Could be used for chaining/multiplying EGs and stuff as=20
well.) Sustain should be an event driven control, rather than a state=20
change call, and the envelope should be programmed using a list of=20
generic sections rather than the fixed DAHDSR parameter set.


Problem is I have to get a real time scripting engine and various=20
hardware drivers to work within a few weeks, so I'm pretty much=20
hacking around the clock. :-/


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Sample Library producers meet LinuxSampler at NAMM :-), was: Release samples, sustain quick release

[David O. <da...@ol...>]

On Thursday 08 January 2004 11.21, be...@ga... wrote:
[...]
> But for the NAMM (begins January, 15) it would be cool if someone
> could produce a quick "hack" like Vladimir did to add simple a
> release envelope to get rid of clicks at note-offs. That way we
> make a much better impression when the sample producer guys will
> listen at it.

I have a simple DAHDSR EG in Audiality. It generates timestamped,=20
sample accurate <target, duration> events that are very easy to=20
handle. Sections are linear only, but I guess that'll do for now.

It's fixed point, but converting to float should be trivial, and I'm=20
going to do that anyway. (Audiality is probably overkill for=20
handhelds and low end games anyway, and all PC style machines and=20
most consoles have decent FPUs these days, at least for floats.)

I'll go have a look at the code...


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Release samples, sustain quick release

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

the sfArk decompression utility (for Windows) works without any problem
under Linux using Wine.
download the sample in .sfark format.
download SfArk from http://www.melodymachine.com/sfark.htm
wine sfark_setup.exe
and then use the application's filedialog to load and decompress the file.
easier than that ? :-)
Anyway those samples are in SF2 format so for now of little use for LinuxSampler.

BTW in my post about the Sample Library producers
I forgot to say that those that will come at NAMM 
agreed to give us a few free sampling CDs that LinuxSampler developers can
use for development and testing purposes. Very nice !

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

Scrive Mark Constable <ma...@re...>:

> > > http://www.musik.auc.dk/~bovbjerg/piano4.html
> 
> Glug. Sorry to be boring but would anyone have a plain 
> uncompressed linux-friendly version of any of these files
> available online somewhere, particluarly the gig ?
> 
> --markc
> 
> 


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

[Linuxsampler-devel] Sample Library producers meet LinuxSampler at NAMM :-), was: Release samples, sustain quick release

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

Great Vladimir !

I'm heading to NAMM ( http://www.thenammshow.com/ ) with
a company that produces Linux based musical instruments (
http://www.lionstracs.com ).

I asked on northernsounds.com (a forum frequented by sample library producers,
hollywood composers etc :-) ), if anyone wants to see LinuxSampler in action
and that we seek collaboration with sample library producers and the response
was very positive.

see my post here:
http://www.northernsounds.com/ubb/NonCGI/ultimatebb.php?ubb=get_topic;f=3;t=006841;p=1

For now about 3-4 well known sample library producers have agreed to speak with
 us. That's very nice, they see the big potential of LS.


But for the NAMM (begins January, 15) it would be cool if someone could produce
a quick "hack" like Vladimir did to add simple a release envelope to get rid of
clicks at note-offs. That way we make a much better impression when the sample
producer guys will listen at it.
Unfortunately I have no time to lend you a hand because this weeek is very
stressful so it would be cool if Vladimir together with Christian and others
could produce this quick "release envelope hack" to show off at NAMM.
(the important thing is that it should not crash when you press/release sustain)


I count on you guys ! (let me know here on the mailing list if you produce a
patch for that date).

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



Scrive Vladimir Senkov <ha...@so...>:

> 
> Anyway, long story short the only thing that i didn't enjoy about linux
> sampler was that clicking noise that results from no release sample support,
> so i've decided to try to do something about it.


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

Re: [Linuxsampler-devel] Release samples, sustain quick release

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

On Wed, 2004-01-07 at 18:59, Vladimir Senkov wrote:

> My dirty hack was not about playing release samples from the gig file. It
> was actually about 3 things:
> 1) Keeping playing whatever is to be played instead of killing the voice
> 2) Gradually reduce the volume of that "to be killed" voice using some curve
> 3) Eventually kill the voice when it's "would be effective volume" gets low
> enough.
> 
> So it is generating a release envelope, not playing one from the sample.

Actually, that sort of thinking can be very valuable I think. Most gig
files don't have release samples, so good strategies for handling them
is a great thing to build up some understanding around.

> It does (as far as i can tell) remove the clicks, but for "realistic" sound
> you do need release samples from the gig file too as far as i understand.

For the pianos, yes...


> 
> I'm adjusting the effective volume from whatever it would otherwise be if i
> just kept playing the note forever.
> I'm them removing a % from that effective vol

Yes, I can see that now with your explanation. Thanks.

<SNIP>
> It was late at night though so my hearing might not have been at it's best
> :)

My ears are old. I know their hearing is not the best. ;-)

> 
> >    Anyway, very good to have you here and I look very forward to trying
> > out your patches.
> 
> I'm currently not doing the right thing about sustain state of that voice
> and something else so i'll probably have to research that before creating
> any kind of a meaningful patch.
> 

Even playing wit just your computed release envelopes will be
interesting.

Re: [Linuxsampler-devel] Release samples, sustain quick release

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

Mark,

> sounds like you are a better keyboardist than I which will help also!)

Doubt it . . . i haven't had any serious practice for almost 10 years now :(

>    I think that I'd love to try out your release sample patches when you
> are ready. However, release samples are only part of the click and pop
> problem. Since many gig files do not have release samples there needs to
> be some sort of envelope placed on the signal being played, taking its
> value down to 0 at a known rate, to eliminate all of the clicks.

My dirty hack was not about playing release samples from the gig file. It
was actually about 3 things:
1) Keeping playing whatever is to be played instead of killing the voice
2) Gradually reduce the volume of that "to be killed" voice using some curve
3) Eventually kill the voice when it's "would be effective volume" gets low
enough.

So it is generating a release envelope, not playing one from the sample.
It does (as far as i can tell) remove the clicks, but for "realistic" sound
you do need release samples from the gig file too as far as i understand.

>    I don't know the term for double clutching the sustain pedal, and
> actually I hadn't noticed this before, so there is certainly something
> there we need to look into.

>    I'll need to think a bit about your general math ideas for doing the
> release. I'm a bit tired this evening, but I'm not clear how you are
> varying the energy of the release sample based on what the current
> volume of the playing sample is? I.e. - If you play a loud note, and
> then release fairly quickly, to move cleanly into that note we have to
> do nothing to that release sample. However, if you play a sustained
> piano note, but wait 10 seconds before releasing, do we not need to do
> something to make it fit cleanly together? I'm not sure, but I had
> thought so.

I'm adjusting the effective volume from whatever it would otherwise be if i
just kept playing the note forever.
I'm them removing a % from that effective volume when the sound is created.
So it always starts from whatever it was at the time of the release and then
it goes down according to some formula.
Formula whatever it may be should be impelented as a precomputed array but
for now i came up with something that doesn't require any conditional code,
so the code that runs is the same regardless of the voice being in release
state or not.
I use the sqrt() function to give me a curve from anywhere close to 0 to
just about 1.
The theory behind it was initially to have from 0%(0) to 100%(1) of the
volume removed.
I then practiced with this code a little bit and decided to reduce the
effect of that formula to make sound last a bit longer by dividing that 0..1
coefficient by a constant. I found that when the constant was too big the
clicking noise would appear again as this generated release envelope would
not bring the volume low enough. 128 seemed ok.
It was late at night though so my hearing might not have been at it's best
:)

>    Anyway, very good to have you here and I look very forward to trying
> out your patches.

I'm currently not doing the right thing about sustain state of that voice
and something else so i'll probably have to research that before creating
any kind of a meaningful patch.

Regards,
Vladimir.

Re: [Linuxsampler-devel] Release samples, sustain quick release

[Mark C. <ma...@re...>]

> > http://www.musik.auc.dk/~bovbjerg/piano4.html

Glug. Sorry to be boring but would anyone have a plain 
uncompressed linux-friendly version of any of these files
available online somewhere, particluarly the gig ?

--markc

Re: [Linuxsampler-devel] Release samples, sustain quick release

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

Vladimir,
   Ah, you are definitely the high point of my day! It's great to have
another person here working on the code and making LS sound better. Even
better is that you have access to GSt so we can compare notes. (It
sounds like you are a better keyboardist than I which will help also!)

   I think that I'd love to try out your release sample patches when you
are ready. However, release samples are only part of the click and pop
problem. Since many gig files do not have release samples there needs to
be some sort of envelope placed on the signal being played, taking its
value down to 0 at a known rate, to eliminate all of the clicks.

   I don't know the term for double clutching the sustain pedal, and
actually I hadn't noticed this before, so there is certainly something
there we need to look into.

   I'll need to think a bit about your general math ideas for doing the
release. I'm a bit tired this evening, but I'm not clear how you are
varying the energy of the release sample based on what the current
volume of the playing sample is? I.e. - If you play a loud note, and
then release fairly quickly, to move cleanly into that note we have to
do nothing to that release sample. However, if you play a sustained
piano note, but wait 10 seconds before releasing, do we not need to do
something to make it fit cleanly together? I'm not sure, but I had
thought so.

   Anyway, very good to have you here and I look very forward to trying
out your patches.

Cheers,
Mark

On Wed, 2004-01-07 at 17:48, Vladimir Senkov wrote:
> Hi Christian, Everybody!
> 
> I'm so glad i found linuxsampler project. My thanks to everybody for making
> this great idea a reality.
> I am a software engineer now (or at least i was able to trick some
> co-workers into thinking that i am :) but i was raised in a family of
> musicians and had to play the piano for about 8 hours a day since i was 6
> till about 17 so i can still play a little . . .
> And now i can play in Linux! Sampler was one of the last apps i needed
> windows for. Now i'm almost 100% linux :)
> 
> Anyway, long story short the only thing that i didn't enjoy about linux
> sampler was that clicking noise that results from no release sample support,
> so i've decided to try to do something about it.
> I'd like to help out on this project (if i can).
> Unfortunately, my coding experience is all in embedded and networking and
> not at all in audio so my attempt to solve the clicking problem is more of a
> research or an ugly hack that probably has no long term value. That's why i
> don't want to send it as a patch but just as a proof of concept, something
> to discuss, etc.
> Anyway, what i did was:
> 1) added a private float to class Voice (i called it "Releasing" for lack of
> imagination)
> it's not actually going to be a float.
> 2) set that to 0 in the constructor
> 3) in Voice::RenderAudio() i added this at the beginning:
>     if (Releasing > 0.9999) {
>  Releasing = 0;
>  PlaybackState = playback_state_end;
>     }
> 4) added a method to voice class:  void Release() { Releasing = 0.000001; }
> again, please disregard these weird constants for now.
> 5) in AudiThread::ReleaseVoice() replaced pVoice->Kill() with
> pVoice->Release() just like the comment said. For now i also put return;
> right after that but that needs to be implemented correctly.
> 6) in both stereo and mono Interpolate inline functions, i've added the
> following:
>      effective_volume = effective_volume - (effective_volume *
> (Releasing/128));
>      Releasing = sqrt(Releasing);
> sqrt and division by 128 are just here for proof of concept code. they will
> not actually be needed.
> Releasing doesn't need to be float either. there can just be a precalculated
> array and Releasing could be an index in such array and effective volume
> could be adjusted based on the value in that array. This way there will be
> no need for any conditional stuff in tight loops either.
> 
> The point of that code was again just to see if something simple like this
> could actually sound OK.
> And you know . . . IMHO it does. I have pretty good hearing, pretty good
> headphones and i can't hear any clicking at all.
> I've compared it to GS and i can't really tell the difference (at least not
> with the samples i have).
> I've played using a few different samples, with and without sustain, mostly
> mono, mostly Soeren Bovbjerg's Steinway sample.
> Christian, I think you've asked a while ago somewhere on usenet about free
> piano samples. This one is free and IMHO pretty good.
> If you don't have it yet, check it out:
> http://www.musik.auc.dk/~bovbjerg/piano4.html
> CPU utilization on my old 850Mhz Athlon did not seem to change much either
> even though it was doing lots of sqrt()s :)
> I'd like to know what the pros think about this simple method. So shoot, but
> please don't kill.
> On the other hand . . . kill, why not? :)
> If this was already discussed and decided upon, please don't kick too hard .
> . .
> 
> About sustain . . . you probably already know this, but anyway. I'm not sure
> what the right terminology for this is, but when i quickly release and apply
> sustain right back in GS what i get is the sound is still alive. Just like a
> real piano. Not in LS though :( As soon as i release the sound is dead. It
> may sound insignificant but when you play certain peices like one of
> Rachmaninov's preludes or for instance where sustain is used a lot you don't
> get the same realistic feel that you do with gs.
> What do you guys think?
> 
> Regards,
> Vladimir.
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Release samples, sustain quick release

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

Hi Christian, Everybody!

I'm so glad i found linuxsampler project. My thanks to everybody for making
this great idea a reality.
I am a software engineer now (or at least i was able to trick some
co-workers into thinking that i am :) but i was raised in a family of
musicians and had to play the piano for about 8 hours a day since i was 6
till about 17 so i can still play a little . . .
And now i can play in Linux! Sampler was one of the last apps i needed
windows for. Now i'm almost 100% linux :)

Anyway, long story short the only thing that i didn't enjoy about linux
sampler was that clicking noise that results from no release sample support,
so i've decided to try to do something about it.
I'd like to help out on this project (if i can).
Unfortunately, my coding experience is all in embedded and networking and
not at all in audio so my attempt to solve the clicking problem is more of a
research or an ugly hack that probably has no long term value. That's why i
don't want to send it as a patch but just as a proof of concept, something
to discuss, etc.
Anyway, what i did was:
1) added a private float to class Voice (i called it "Releasing" for lack of
imagination)
it's not actually going to be a float.
2) set that to 0 in the constructor
3) in Voice::RenderAudio() i added this at the beginning:
    if (Releasing > 0.9999) {
 Releasing = 0;
 PlaybackState = playback_state_end;
    }
4) added a method to voice class:  void Release() { Releasing = 0.000001; }
again, please disregard these weird constants for now.
5) in AudiThread::ReleaseVoice() replaced pVoice->Kill() with
pVoice->Release() just like the comment said. For now i also put return;
right after that but that needs to be implemented correctly.
6) in both stereo and mono Interpolate inline functions, i've added the
following:
     effective_volume = effective_volume - (effective_volume *
(Releasing/128));
     Releasing = sqrt(Releasing);
sqrt and division by 128 are just here for proof of concept code. they will
not actually be needed.
Releasing doesn't need to be float either. there can just be a precalculated
array and Releasing could be an index in such array and effective volume
could be adjusted based on the value in that array. This way there will be
no need for any conditional stuff in tight loops either.

The point of that code was again just to see if something simple like this
could actually sound OK.
And you know . . . IMHO it does. I have pretty good hearing, pretty good
headphones and i can't hear any clicking at all.
I've compared it to GS and i can't really tell the difference (at least not
with the samples i have).
I've played using a few different samples, with and without sustain, mostly
mono, mostly Soeren Bovbjerg's Steinway sample.
Christian, I think you've asked a while ago somewhere on usenet about free
piano samples. This one is free and IMHO pretty good.
If you don't have it yet, check it out:
http://www.musik.auc.dk/~bovbjerg/piano4.html
CPU utilization on my old 850Mhz Athlon did not seem to change much either
even though it was doing lots of sqrt()s :)
I'd like to know what the pros think about this simple method. So shoot, but
please don't kill.
On the other hand . . . kill, why not? :)
If this was already discussed and decided upon, please don't kick too hard .
. .

About sustain . . . you probably already know this, but anyway. I'm not sure
what the right terminology for this is, but when i quickly release and apply
sustain right back in GS what i get is the sound is still alive. Just like a
real piano. Not in LS though :( As soon as i release the sound is dead. It
may sound insignificant but when you play certain peices like one of
Rachmaninov's preludes or for instance where sustain is used a lot you don't
get the same realistic feel that you do with gs.
What do you guys think?

Regards,
Vladimir.

[Linuxsampler-devel] LinuxSampler control protocol (3rd and possible final draft)

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

Hi!

I updated the protocol document:

        http://www.linuxsampler.org/api/draft-linuxsampler-protocol-02.pdf
        http://www.linuxsampler.org/api/draft-linuxsampler-protocol-02.sxw

Changes:

	- the response of LS on a successful subscription of the frontend with
	  "SUBSCRIBE NOTIFICATION" now looks like this:

		"OK[<session-id>]"

	- the command for unsubscribing the frontend now looks like that:

		"UNSUBSCRIBE NOTIFICATION <session-id>"

	  Parameter <session-id> is not optional.

As demanded, I also added these links to the "Downloads" section on the 
LinuxSampler webpage today:

	http://www.linuxsampler.org/downloads.html

CU
Christian