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

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

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

On Sun, 2004-01-11 at 15:55, Christian Schoenebeck wrote:

> > 	* Is Delay a minimum note-off->release delay,
> > 	  the maximum duration of the sustain state,
> > 	  or what? (Both seem useful to me...)
> 
> That 2nd "D" is actually Decay2. It's an exponential fall from the last Decay1 
> level to the first level of the Release stage. Decay2 will only become 
> applied in case this "infinite sustain" is disabled, but I'm not that sure. 
> Maybe Mark can confirm that?

I believe this is a correct description. 

With Infinite Sustain enabled Decay 2 is not used.

With Infinite Sustain disabled, Decay 2 begins at the end of Decay 1.
This appears (in my mind) to create a first, normally faster decay
region like everyone is used to. After that first decay period, Decay 2
kicks in and GSt will then does a second decay period that takes you
down to 0 volume. I think the intention here is to ensure that all notes
eventually go to zero even if their keys are never released.

This does raise one unsolved issue I've seen with LS. To date I think LS
has no mechanism for releasing the oldest notes when it reaches its
maximum note count. Press sustain and start hitting keys. Eventually you
get messages about not being able to play notes.

LS needs to be able to release the oldest notes to that new notes can be
played. Generally it will be better to get a release or something from
very old notes going away vs. not playing the newest notes.

Cheers,
Mark

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

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

Es geschah am Montag, 12. Januar 2004 00:55 als Christian Schoenebeck schrieb:
> Maybe I should clearify the development roadmap: First we'll finish a
> complete Gig Engine, restructure LS for multi engine support, add network
> socket for the LSCP so we can control LS with a GUI (Qt GUi, VSTi host and
> whatever). Then we will implement other engines, like Akai engine, DLS
> engine perhaps, ...  and as well as our own very modular engine which will
> get all the features you just can dream about. For that we'll add the
> recompilation feature which just came out of Benno's mind. This means you
> will be able e.g. select all the features you want to have in your very
> custom sampler engine, click an "Apply" button in the GUI and on LS side
> your custom engine will just be compiled and deployed in realtime. So you
> have your own custom engine that is as efficient as it only could be. There
> are really a lot of parameter here where you could choose from: e.g. as
> mentioned which kind of EG to be used (and how many of them, with which
> influence), frequency of the event handling (sample accurate or an
> arbitrary frequency), various filters (or even no filter at all - to save
> CPU cycles), various interpolators (simple lin., cubic or even a
> sophisticated interpolator with formant frequency correction),  and and
> and....
>
> For example if somebody needs an Engine for playbing samples or something,

Argh, sorry, I mean "playing drum samples or something" :)

> he wouldn't probably need to pitch the samples at all, so he will disable
> interpolation and things like modulators completely and thus saves CPU
> cycles. Or if somebody wants to use real (singer) voices, he'll probably
> needs a more heavy setup with an interpolator that is capable to correct
> formant frequencies, so the voices don't sound unnaturally if pitched over
> several semi tones.
>
> That's the idea and overall roadmap for LinuxSampler I currently have in
> mind.
>
> CU
> Christian
>
>
>
> -------------------------------------------------------
> 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

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

Es geschah am Montag, 12. Januar 2004 00:15 als Mattias Henningson schrieb:
> Ok, it seems he's actually been planning a Linux version of the FXT server.
> No planned timetable though so far and without no doubt the Mac version (OS
> X btw so it's not too different) has precedence right now... Anyway, LS
> would need to support Jack or LADSPA in order to work with the FXT server
> when it finally shows up. I'm very new here but didn't I at least read
> something about Jack support the other day? If that is the case both
> solutions (FXT and the "native" LS solution) could be used.

Yeah, Jack will be added very soon to LS. We just slightly have to modify the 
structure of LS a bit for this, because the audio render loop is currently 
(due to Alsa) polling based. For Jack we'll need it event based, so Jack 
calls LS when it wants to have the next audio fragment to be rendered. This 
requires only little changes, it has to be done though.

CU
Christian

[Linuxsampler-devel] Roadmap (was: Latest CVS commit)

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

Es geschah am Sonntag, 11. Januar 2004 23:20 als David Olofson schrieb:
> On Sunday 11 January 2004 18.10, Christian Schoenebeck wrote:
> [..]
>
> > PADSDR
>
> [..]
>
> ???-Attack-Decay-Sustain-Delay-Release?
>
> Some questions:
> 	* What's the first state?

Sorry, that's just the PreAttack value, thus the value from which the Attack 
stage will start. That's actually already honored in the current EG. The EG 
sequence is as follows:

Attack (start from PreAttack value) -> [ optionally] hold -> Decay1 -> Decay2 
or instead Sustain (this is a flag option) -> Release

>
> 	* Why no Hold between Attack and Decay?
> 	  (Nice for tweaking fast, percussive sounds.)

Yes, that will definitely be added. The Giga format has a flag for this in the 
patch format to turn this on / off (for those who don't know what we're 
talking about - this "hold" parameter will postpone the first Decay stage 
until the sample playback reached the loop begin). But again, I'm just very 
priority driven at the moment. I first do all the basic things with the 
highest priority and postpone fine adjustments later if that doesn't hurt the 
design.

>
> 	* Is Delay a minimum note-off->release delay,
> 	  the maximum duration of the sustain state,
> 	  or what? (Both seem useful to me...)

That 2nd "D" is actually Decay2. It's an exponential fall from the last Decay1 
level to the first level of the Release stage. Decay2 will only become 
applied in case this "infinite sustain" is disabled, but I'm not that sure. 
Maybe Mark can confirm that?

>
> Anyway, I still prefer generic N-stage EGs, something like those in
> FastTracker (and clones) and some h/w synths. They can easily be
> extended with conditional loops and stuff, to handle release and to
> double as event sync'ed LFOs.

Of course, we'll add an artbitrary N-stage EG later, but at the moment the 
goal is just to fullfill all Giga synthesis requirements and Giga has only 
that mentioned EG.

Maybe I should clearify the development roadmap: First we'll finish a complete 
Gig Engine, restructure LS for multi engine support, add network socket for 
the LSCP so we can control LS with a GUI (Qt GUi, VSTi host and whatever). 
Then we will implement other engines, like Akai engine, DLS engine 
perhaps, ...  and as well as our own very modular engine which will get all 
the features you just can dream about. For that we'll add the recompilation 
feature which just came out of Benno's mind. This means you will be able e.g. 
select all the features you want to have in your very custom sampler engine, 
click an "Apply" button in the GUI and on LS side your custom engine will 
just be compiled and deployed in realtime. So you have your own custom engine 
that is as efficient as it only could be. There are really a lot of parameter 
here where you could choose from: e.g. as mentioned which kind of EG to be 
used (and how many of them, with which influence), frequency of the event 
handling (sample accurate or an arbitrary frequency), various filters (or 
even no filter at all - to save CPU cycles), various interpolators (simple 
lin., cubic or even a sophisticated interpolator with formant frequency 
correction),  and and and....

For example if somebody needs an Engine for playbing samples or something, he 
wouldn't probably need to pitch the samples at all, so he will disable 
interpolation and things like modulators completely and thus saves CPU 
cycles. Or if somebody wants to use real (singer) voices, he'll probably 
needs a more heavy setup with an interpolator that is capable to correct 
formant frequencies, so the voices don't sound unnaturally if pitched over 
several semi tones.

That's the idea and overall roadmap for LinuxSampler I currently have in mind.

CU
Christian

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

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

<be...@ga...> wrote:
>
> About FXT, ok but the problem is we want a free windows client.
> I doubt he will make a (even closed source) client for us.
> Or perhaps he will open the protocol and we will use a FXT-compatible
protocol.
> So that LS works with both our free client and with FXT ?
> Or alternatively we develop our own network protocol and since the specs
> are open the FXT guy can add support to FXT so that you can use an LS
machine
> and a FXT client.
> There are many possibilities, but I guess that he will try to keep
> his protocol closed in order to avoid cannibalizing his sales.
Ok, it seems he's actually been planning a Linux version of the FXT server.
No planned timetable though so far and without no doubt the Mac version (OS
X btw so it's not too different) has precedence right now... Anyway, LS
would need to support Jack or LADSPA in order to work with the FXT server
when it finally shows up. I'm very new here but didn't I at least read
something about Jack support the other day? If that is the case both
solutions (FXT and the "native" LS solution) could be used.

> Anyway network streaming is not as hard as one might think,
> Some tunable client buffering and it works.
> Writing a VSTi is not hard either, the APIs are really straightforward.
Agreed, this is at least something I can confirm. I've touched network
streaming in a few projects and I've messed a bit with the VST SDK too
lately and it's very straight-forward.

> Since LS usues a TCP socket for the GUI controls and since we plan
> to use the Qt library (which allows for crossplatform GUI code) so
> we can embed the GUI controls directly into the VSTi without problem.
> This would be userfriendly since you have an all-in-one solution.
Very cool solution.

/Mattias

Re: [Linuxsampler-devel] Latest CVS commit

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

On Sun, 2004-01-11 at 14:02, Vladimir Senkov wrote:

> But . . . I think a bug got introduced in the process.
> Occasionally, some notes will not release completely. They'll get stuck 
> in a state where i can still hear them but their volume is lower than usual.
> If i play the same note again it goes away.
> Kinda feels like a stuck key :) But it's not, because when i play the 
> same thing with old ls (pre cvs update) i don't get into that state.

Vladimir - what version of Alsa are you using? I just upgraded to 1.0.1
and am having this problem. I did not notice it with 1.0.0-rc2

Mark

Re: [Linuxsampler-devel] Latest CVS commit

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

Hi,
   I'm hearing the same note-on problems that Vladimir is hearing also.
I've posted the jazz bounce done on my end on Pro Tools with the new
version of LS at:

http://marksmusic.myvnc.com/files/LS_Bounce-2004-01-11.ogg

If you listen closely you'll hear a few places where this note-on
problem happens. Additionally, I found that usually when I'd finished
the MIDI sequence even LS itself knew it had notes on. All notes had
quite playing, but the note count had not returned to 100 and LS said it
still had 1 stream active.

None the less, this is a huge step up in terms of quality. The previous
versions (GSt and LS) are here:

http://marksmusic.myvnc.com/files/GSt_Bounce-2003-12-21.ogg
http://marksmusic.myvnc.com/files/LS_Bounce-2003-12-21.ogg

Comparisons are not totally fair as the earlier 2 I had put a bit of
reverb on them. This was a mistake for listening for problems, so I
think that I will not do that in this forum again.

FYI - This server is normally up between 5AM and 10PM California time,
so listen during those times.

Great work!!

Cheers,
Mark

On Sun, 2004-01-11 at 14:02, Vladimir Senkov wrote:
> Christian,
> 
> Awesome!!!
> I can't hear any noises at all with that free Steinway sample and 
> default settings.
> 
> But . . . I think a bug got introduced in the process.
> Occasionally, some notes will not release completely. They'll get stuck 
> in a state where i can still hear them but their volume is lower than usual.
> If i play the same note again it goes away.
> Kinda feels like a stuck key :) But it's not, because when i play the 
> same thing with old ls (pre cvs update) i don't get into that state.
> 
> After a while i found a way to reproduce: (other ways may exist also)
> 1) play and hold note. (voices: 1)
> 2) apply and hold sustain.
> 3) release the note (keeps playing on sustain)
> 4) play and hold the same note again (voices: 2)
> 4) release sustain
> 5) apply sustain (hold)
> 6) release the note
> 7) release sustain. (voices: 2!)
> Voices will still be allocated and playing at this point!
> 
> I'd love to implement PADSDR but i hope it's not very urgent as i need 
> to do a bit of reading first.
> 
> Regards,
> Vladimir.
> 
> Christian Schoenebeck wrote:
> 
> >Changes:
> >
> >	-  There was still this annoying problem that some .gig instruments were
> >	   detuned. I hope I have fixed this now. If you have still a .gig that
> >	   sounds detuned, please let me know!
> >
> >	- As promised I finished an initial version of the amplitude envelope
> >	   generator (EG1), so far only a simple ASR one. Extending it to a PADSDR
> >	   one (as used in Gigasampler) is quite easy. If anybody likes to do this
> >	   task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir
> >	   perhaps?
> >	   The EG has a minimum release time, in case the release time given by the
> >	   gig file is 0s for example. Without this min. release time we would again
> >	   have the click problem in case of zero release times when the voice will
> >	   be released before it's sample end. This min. release time is defined in
> >	   line 32 of src/eg_vca.h and there's another #define which sets the bottom
> >	   value limit of the Exp curve, thus also defines the end of the EG curve in
> >	   general. These two #define values still have to be adjusted to good values
> >
> >CU
> >Christian
> >
> >
> >
> >-------------------------------------------------------
> >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 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] Latest CVS commit

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

On Sunday 11 January 2004 18.10, Christian Schoenebeck wrote:
[..]
> PADSDR
[..]

???-Attack-Decay-Sustain-Delay-Release?

Some questions:
=09* What's the first state?

=09* Why no Hold between Attack and Decay?
=09  (Nice for tweaking fast, percussive sounds.)

=09* Is Delay a minimum note-off->release delay,
=09  the maximum duration of the sustain state,
=09  or what? (Both seem useful to me...)


Anyway, I still prefer generic N-stage EGs, something like those in=20
FastTracker (and clones) and some h/w synths. They can easily be=20
extended with conditional loops and stuff, to handle release and to=20
double as event sync'ed LFOs.

The implementation is really rather similar to that of an ADSR, DAHDSR=20
or whatever, except that you have only one state, supporting whatever=20
transition methods you need, and then a list of arbitrary lenght,=20
containing now parameters for each section of the envelope.


//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] Latest CVS commit

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

Christian,

Awesome!!!
I can't hear any noises at all with that free Steinway sample and 
default settings.

But . . . I think a bug got introduced in the process.
Occasionally, some notes will not release completely. They'll get stuck 
in a state where i can still hear them but their volume is lower than usual.
If i play the same note again it goes away.
Kinda feels like a stuck key :) But it's not, because when i play the 
same thing with old ls (pre cvs update) i don't get into that state.

After a while i found a way to reproduce: (other ways may exist also)
1) play and hold note. (voices: 1)
2) apply and hold sustain.
3) release the note (keeps playing on sustain)
4) play and hold the same note again (voices: 2)
4) release sustain
5) apply sustain (hold)
6) release the note
7) release sustain. (voices: 2!)
Voices will still be allocated and playing at this point!

I'd love to implement PADSDR but i hope it's not very urgent as i need 
to do a bit of reading first.

Regards,
Vladimir.

Christian Schoenebeck wrote:

>Changes:
>
>	-  There was still this annoying problem that some .gig instruments were
>	   detuned. I hope I have fixed this now. If you have still a .gig that
>	   sounds detuned, please let me know!
>
>	- As promised I finished an initial version of the amplitude envelope
>	   generator (EG1), so far only a simple ASR one. Extending it to a PADSDR
>	   one (as used in Gigasampler) is quite easy. If anybody likes to do this
>	   task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir
>	   perhaps?
>	   The EG has a minimum release time, in case the release time given by the
>	   gig file is 0s for example. Without this min. release time we would again
>	   have the click problem in case of zero release times when the voice will
>	   be released before it's sample end. This min. release time is defined in
>	   line 32 of src/eg_vca.h and there's another #define which sets the bottom
>	   value limit of the Exp curve, thus also defines the end of the EG curve in
>	   general. These two #define values still have to be adjusted to good values
>
>CU
>Christian
>
>
>
>-------------------------------------------------------
>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] Latest CVS commit

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

On Sun, 2004-01-11 at 10:20, Mark Knecht wrote:

>    Oops - spoke a bit too soon. OK, when I first tried using LS I had
> the fragment size set at 128. I then Ctrl-C'ed out and tried it with
> 512. I no longer get any audio. I see no MIDI events coming in, which
> would explain no audio. kaconnect does show my keyboard is hooked up to
> LS. Strange. I've not seen this problem before.
> 
>    FYI - This is Alsa-1.0.1
> 
>    I've killed it and gone back to 128, but still not working. Here's my
> command line.
> 
>  linuxsampler  --numfragments 2 --fragmentsize 128 --inputclient 80:1
> --instrument 0 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\
> Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig 
> 

OK, very strange. After doing that Ctrl-C out of LS no audio that I
tried would work anymore. (xmms, alsaplayer) They all seemed to be
blocked or something. I stopped and restarted Alsa but they didn't work.
I rebooted and they were still not working. I had to completely power
down to get audio back again.

Now I'm going in and out of LS just fine. I'm not getting the clicks
when I start LS with a 512 fragment size.

I'll post my jazz MIDI test file later today and hold judgment on this
audio crash until I get convinced it was a one time event.

Cheers,
Mark

Re: [Linuxsampler-devel] Latest CVS commit

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

On Sun, 2004-01-11 at 09:10, Christian Schoenebeck wrote:
> Changes:
> 
> 	-  There was still this annoying problem that some .gig instruments were
> 	   detuned. I hope I have fixed this now. If you have still a .gig that
> 	   sounds detuned, please let me know!
> 
> 	- As promised I finished an initial version of the amplitude envelope
> 	   generator (EG1), so far only a simple ASR one. Extending it to a PADSDR
> 	   one (as used in Gigasampler) is quite easy. If anybody likes to do this
> 	   task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir
> 	   perhaps?
> 	   The EG has a minimum release time, in case the release time given by the
> 	   gig file is 0s for example. Without this min. release time we would again
> 	   have the click problem in case of zero release times when the voice will
> 	   be released before it's sample end. This min. release time is defined in
> 	   line 32 of src/eg_vca.h and there's another #define which sets the bottom
> 	   value limit of the Exp curve, thus also defines the end of the EG curve in
> 	   general. These two #define values still have to be adjusted to good values
> 
> CU
> Christian

Christian,
   Wow!! That's a huge improvement! I've built the new version. It
sounds much better. I am getting a few clicks with a fragment size of
128. They do not sound like they are coming at release times, so I'll
fire up Pro Tools and do some recording of this version and study what's
up with that. It could just be my system.

   Anyway, great work! Much much better!

   Oops - spoke a bit too soon. OK, when I first tried using LS I had
the fragment size set at 128. I then Ctrl-C'ed out and tried it with
512. I no longer get any audio. I see no MIDI events coming in, which
would explain no audio. kaconnect does show my keyboard is hooked up to
LS. Strange. I've not seen this problem before.

   FYI - This is Alsa-1.0.1

   I've killed it and gone back to 128, but still not working. Here's my
command line.

 linuxsampler  --numfragments 2 --fragmentsize 128 --inputclient 80:1
--instrument 0 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\
Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig 


Cheers,
Mark

Re: [Linuxsampler-devel] Latest CVS commit

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

SORRY!!! Stupid me! You show that in the previous release!

My apologies!!!

- Mark

On Sun, 2004-01-11 at 09:56, Mark Knecht wrote:
> Christian,
>    Going to get it now. I do not see in the LS front page description of
> this release that you added the two fixes you and I worked on last
> weekend. Did those get included?
> 
> Thanks,
> Mark
> 
> On Sun, 2004-01-11 at 09:10, Christian Schoenebeck wrote:
> > Changes:
> > 
> > 	-  There was still this annoying problem that some .gig instruments were
> > 	   detuned. I hope I have fixed this now. If you have still a .gig that
> > 	   sounds detuned, please let me know!
> > 
> > 	- As promised I finished an initial version of the amplitude envelope
> > 	   generator (EG1), so far only a simple ASR one. Extending it to a PADSDR
> > 	   one (as used in Gigasampler) is quite easy. If anybody likes to do this
> > 	   task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir
> > 	   perhaps?
> > 	   The EG has a minimum release time, in case the release time given by the
> > 	   gig file is 0s for example. Without this min. release time we would again
> > 	   have the click problem in case of zero release times when the voice will
> > 	   be released before it's sample end. This min. release time is defined in
> > 	   line 32 of src/eg_vca.h and there's another #define which sets the bottom
> > 	   value limit of the Exp curve, thus also defines the end of the EG curve in
> > 	   general. These two #define values still have to be adjusted to good values
> > 
> > CU
> > Christian
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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 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] Latest CVS commit

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

Christian,
   Going to get it now. I do not see in the LS front page description of
this release that you added the two fixes you and I worked on last
weekend. Did those get included?

Thanks,
Mark

On Sun, 2004-01-11 at 09:10, Christian Schoenebeck wrote:
> Changes:
> 
> 	-  There was still this annoying problem that some .gig instruments were
> 	   detuned. I hope I have fixed this now. If you have still a .gig that
> 	   sounds detuned, please let me know!
> 
> 	- As promised I finished an initial version of the amplitude envelope
> 	   generator (EG1), so far only a simple ASR one. Extending it to a PADSDR
> 	   one (as used in Gigasampler) is quite easy. If anybody likes to do this
> 	   task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir
> 	   perhaps?
> 	   The EG has a minimum release time, in case the release time given by the
> 	   gig file is 0s for example. Without this min. release time we would again
> 	   have the click problem in case of zero release times when the voice will
> 	   be released before it's sample end. This min. release time is defined in
> 	   line 32 of src/eg_vca.h and there's another #define which sets the bottom
> 	   value limit of the Exp curve, thus also defines the end of the EG curve in
> 	   general. These two #define values still have to be adjusted to good values
> 
> CU
> Christian
> 
> 
> 
> -------------------------------------------------------
> 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

[Linuxsampler-devel] Latest CVS commit

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

Changes:

	-  There was still this annoying problem that some .gig instruments were
	   detuned. I hope I have fixed this now. If you have still a .gig that
	   sounds detuned, please let me know!

	- As promised I finished an initial version of the amplitude envelope
	   generator (EG1), so far only a simple ASR one. Extending it to a PADSDR
	   one (as used in Gigasampler) is quite easy. If anybody likes to do this
	   task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir
	   perhaps?
	   The EG has a minimum release time, in case the release time given by the
	   gig file is 0s for example. Without this min. release time we would again
	   have the click problem in case of zero release times when the voice will
	   be released before it's sample end. This min. release time is defined in
	   line 32 of src/eg_vca.h and there's another #define which sets the bottom
	   value limit of the Exp curve, thus also defines the end of the EG curve in
	   general. These two #define values still have to be adjusted to good values

CU
Christian

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

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

On Sun, 2004-01-11 at 08:42, Tobias Erichsen wrote:

> Sounds pretty good... I have done a little bit of work with
> VSTs (was thinking about developing my own vst-host before I
> went off with the asio2ks project) - i'm not really that much
> of a gui-designer - and a vst-host needs some good gui. 
> 

Cool! Good to have another interested developer.

I don't mean to throw water on any folks fire about doing a
Windows-based front-ends, but just to lobby for a bit more balance. If
you or others could become more interested in the internals of LS, then
the real tool could move forward more quickly.

As a potential user of LS I will point out though that even if we had a
gorgeous PC/Mac VST type interface, we'd still be talking to a version
of LS that is missing conservatively at least 15-20 features it needs to
be compatible with even my desired GSt platform, much less adding all
the interesting stuff other folks are looking for like Kontakt & Battery
type features. (And I'll list the features if requested...)

So, do what you want since that's the way Open Source development works,
but at least consider jumping in and adding features to LS itself. If I
had the talent you guys do that's where I'd try to put my efforts. It
wouldn't be easy, but I think the most valuable. None the less, whatever
you and others decide to do will be of great value and it's good to have
you here.

Cheers,
Mark

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

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

Es geschah am Sonntag, 11. Januar 2004 17:42 als Tobias Erichsen schrieb:
> Sounds pretty good... I have done a little bit of work with
> VSTs (was thinking about developing my own vst-host before I
> went off with the asio2ks project) - i'm not really that much
> of a gui-designer - and a vst-host needs some good gui.

No problem, Rui already works on a Qt GUI for LS, so you don't have to write 
your own GUI. You simply would have to embed his Qt GUI in your VSTi host. 
Should be quite easy for you.

CU
Christian

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

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

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> be...@ga...
> Sent: Sunday, January 11, 2004 1:57 AM
> To: Linux-Sampler
> Subject: RE: [Linuxsampler-devel] Win32-Integration-Proposal
> 
> 
> About Rewire:
> this post seems rather discouraging, their license seems 
> incompatible with
> open source:
> http://techweb.rfa.org/pipermail/portaudio/2003-April/001827.html
> 
> I still think a VST windows network frontend for LS is the way to go
> (at least during the initial phase).
> there are tons of VST hosts and wrappers so I think a VST module would
>  make many of the windows audio users happy.
> 
> Tobias, comments ?

Sounds pretty good... I have done a little bit of work with
VSTs (was thinking about developing my own vst-host before I
went off with the asio2ks project) - i'm not really that much
of a gui-designer - and a vst-host needs some good gui. 

I think a VST-instrument needs a good gui also, but someone
else could contribute there, as I really don't have any experience
with QT... If you guys think this is ok, I'd like to do some stuff
for the network layer and perhaps even the vst-wrapper for the win32-
part.

I'd use rtp for the audio-signals (same stuff that is used for
VoIP), there's also a draft for midi over rtp, but I'm not sure
if there's any other prot that would be better for midi...

I have not invested that much of time looking at the ls-control-
prot-spec yet, I'd need to do this the next couple of days...
 
Tobias

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

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

Hi Benno,

This newbie got carried away in his ignorance.

LS is going to be soo cool! great architecture.

I have been user interface designer for 9 years, after being software
engineer (multitasking stuff and portable GUI's in Modula-2, long ago).
I run my own 1 person company, Deltaworks :-) I will be following the UI
parts with great interest, maybe I can once contribute some parts.

Take care,

Peter Roos
(www.deltaworks.nl / www.PeterRoos.com)


Benno wrote:

PS: PeterRoos: what did you mean with your post on the NS forum ?
----- 
 Would it be possible to run LinuxSampler as a (system) service (or as
sampler
player "server") with the user interface on a different box, say Win or Mac?
I
think that would be a really cool distribution of the system's components.
It
would allow users to keep working in their familiar environment, after
installing and configuring the LS.
----

It's exactly what we are discussing about :-) Or am I missing something ?

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

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

[Ryan <rui...@co...>]

On Sat, 2004-01-10 at 20:42, Mark Knecht wrote:
> On Sat, 2004-01-10 at 18:25, Ryan wrote:
> 
> > Pluggo from cycling74 is a VST wrapper that does midi with Pro Tools, so
> > I guess that'll allow interested PT professionals to access LS anyway.
> > 
> > http://www.cycling74.com/products/pluggo.html
> > 
> > -ry
> 
> :-( - looks like Mac only?

Oh yeah (I'm so ignorant of the windows world lately, which is nice ;-)
but I read on the site that windows development is on the way and soon
to arrive.

-ry

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

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

On Sat, 2004-01-10 at 18:25, Ryan wrote:

> Pluggo from cycling74 is a VST wrapper that does midi with Pro Tools, so
> I guess that'll allow interested PT professionals to access LS anyway.
> 
> http://www.cycling74.com/products/pluggo.html
> 
> -ry

:-( - looks like Mac only?

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

[Ryan <rui...@co...>]

On Sat, 2004-01-10 at 18:57, be...@ga... wrote:
> About Rewire:
> this post seems rather discouraging, their license seems incompatible with
> open source:
> http://techweb.rfa.org/pipermail/portaudio/2003-April/001827.html
> 
> I still think a VST windows network frontend for LS is the way to go
> (at least during the initial phase).
> there are tons of VST hosts and wrappers so I think a VST module would
>  make many of the windows audio users happy.

Pluggo from cycling74 is a VST wrapper that does midi with Pro Tools, so
I guess that'll allow interested PT professionals to access LS anyway.

http://www.cycling74.com/products/pluggo.html

-ry

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

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

About Rewire:
this post seems rather discouraging, their license seems incompatible with
open source:
http://techweb.rfa.org/pipermail/portaudio/2003-April/001827.html

I still think a VST windows network frontend for LS is the way to go
(at least during the initial phase).
there are tons of VST hosts and wrappers so I think a VST module would
 make many of the windows audio users happy.

Tobias, comments ?

[ VSTi proposal of Mattias .... ]
> 
> 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:

About FXT, ok but the problem is we want a free windows client.
I doubt he will make a (even closed source) client for us.
Or perhaps he will open the protocol and we will use a FXT-compatible protocol.
So that LS works with both our free client and with FXT ?
Or alternatively we develop our own network protocol and since the specs
are open the FXT guy can add support to FXT so that you can use an LS machine
and a FXT client.
There are many possibilities, but I guess that he will try to keep
his protocol closed in order to avoid cannibalizing his sales.

Anyway network streaming is not as hard as one might think,
Some tunable client buffering and it works.
Writing a VSTi is not hard either, the APIs are really straightforward.

Since LS usues a TCP socket for the GUI controls and since we plan
to use the Qt library (which allows for crossplatform GUI code) so
we can embed the GUI controls directly into the VSTi without problem.
This would be userfriendly since you have an all-in-one solution.


> 
> * 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.

Exactly, see above.

> 
> 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.

ok !

PS: PeterRoos: what did you mean with your post on the NS forum ?
----- 
 Would it be possible to run LinuxSampler as a (system) service (or as sampler
player "server") with the user interface on a different box, say Win or Mac? I
think that would be a really cool distribution of the system's components. It
would allow users to keep working in their familiar environment, after
installing and configuring the LS.
----

It's exactly what we are discussing about :-) Or am I missing something ?

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



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

> Hey, I appreciate the support, but DigiDesign has always made it sort of
> hard to support them. Their RTAS stuff requires special agreements to
> get the specs and all. It's always been difficult for us Pro Tools
> folks. Digi added ReWire support with version 6. I don't have any ReWire
> instruments, so I cannot even say if it works or not.
> 
> LS will support Pro Tools right out of the box. It's an external sampler
> just like GSt, so I can use it. It's just another MIDI device. That's
> not bad.
> 
> As far as this whole Windows GUI thing goes, I *think* that this would
> allow VST users to see it within their sequencer GUI, right? I guess the
> goal here is to be able to control what samples are being loaded in
> specific songs on specific tracks and MIDI channels? That would be
> really cool to have in Pro Tools also, I must admit, but I've got so
> little in this environment that I'm just used to begging! ;-)
> 
> 



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

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

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

> > 
> > 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.
> 
> I have to agree.  ProTools is THE professional audio application to many
> many (really most) studio engineers.  VST and ASIO will interest home
> users and amateur musicians but in order for LS to make it's way into
> professional studios ProTools MUST be supported.
> 
> Just my opinion,
> -ry

Hey, I appreciate the support, but DigiDesign has always made it sort of
hard to support them. Their RTAS stuff requires special agreements to
get the specs and all. It's always been difficult for us Pro Tools
folks. Digi added ReWire support with version 6. I don't have any ReWire
instruments, so I cannot even say if it works or not.

LS will support Pro Tools right out of the box. It's an external sampler
just like GSt, so I can use it. It's just another MIDI device. That's
not bad.

As far as this whole Windows GUI thing goes, I *think* that this would
allow VST users to see it within their sequencer GUI, right? I guess the
goal here is to be able to control what samples are being loaded in
specific songs on specific tracks and MIDI channels? That would be
really cool to have in Pro Tools also, I must admit, but I've got so
little in this environment that I'm just used to begging! ;-)

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

[Ryan <rui...@co...>]

On Sat, 2004-01-10 at 08:25, Mark Knecht wrote:
> 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.

I have to agree.  ProTools is THE professional audio application to many
many (really most) studio engineers.  VST and ASIO will interest home
users and amateur musicians but in order for LS to make it's way into
professional studios ProTools MUST be supported.

Just my opinion,
-ry

[Linuxsampler-devel] Free gigs

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

Hi,
   I find that Worra's Place is back up. I guess it's been up for a
couple of months now. Check it out. There is no reason for anyone to not
have access to gig files as long as this one is running.

http://www.worrasplace.com

Cheers,
Mark