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

Re: [Linuxsampler-devel] example LSCP scripts

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

Hi Robert,

I think the clicking you are hearing is related to the voice stealing 
work that Christian has just put in, it is still work in progress . . . 
as such he had to tweak a few things in the envelope generator (for the 
time being).
So your headphones are probably fine :)

Regards,
Vladimir.

Robert Jonsson wrote:

>Hi guys,
>
>tisdagen den 21 september 2004 23.04 skrev Vladimir Senkov:
>  
>
>>Hi Robert,
>>
>>Please make sure you're running the latest LS. I've made a check-in a
>>few days ago that fixed a small problem with panning that caused LS to
>>be silent. I'm hoping it's the same problem you have at the moment so
>>things should be working again once you take an update from cvs.
>>Sorry about that, bad timing :(
>>    
>>
>
>Actually I had updated the tree.
>I had me a doze of inspiration and started poking at it again. And as it 
>happens I was trying the wrong startup script (I am curently not running 
>through the GUI)...sorry... I think I'm a little over worked ;)...
>
>As for the crash bug, I haven't seen it... though I didn't play that long. 
>Seems solid enough. 
>I noticed the grouping has started to work also. Great! Atleast on some of the 
>samples. I have to check with that GIG utility what samples really are in the 
>group, probably it's correct but I think there should be more of them.
>
>Also, I have new headphones...don't know if it's that or if it's been there 
>all along but I'm starting to hear artifacts in the sound. Clicking at the 
>end of the samples... and some very strange sound when "shutting of" a long 
>sound with a short one (in a group). I will try to record some examples so 
>you can hear what I'm trying to describe. Not tonight though.
>
>/Robert
>
>  
>
>>It is usually a good idea to visit the news page on the LS website to
>>see if there were any recent updates to the code that might fix an issue
>>(if you have any). We try to put descriptive notes there to make it
>>easier to figure out if it's the same problem or not.
>>
>>Regards,
>>Vladimir.
>>
>>Robert Jonsson wrote:
>>    
>>
>>>måndagen den 20 september 2004 20.33 skrev Robert Jonsson:
>>>      
>>>
>>>>Hi,
>>>>
>>>>söndagen den 12 september 2004 04.06 skrev Vladimir Senkov:
>>>>        
>>>>
>>>>>Hi Robert,
>>>>>
>>>>>I've just checked something in, could you try to reproduce this problem
>>>>>with the latest cvs?
>>>>>          
>>>>>
>>>>Long response times here, sorry. I'll try to hammer away at this a bit
>>>>tonight, will see what happens.
>>>>        
>>>>
>>>Ack, bad times... I didn't even manage to get any sound at all. I've used
>>>up my timeslice for a few more days so I will likely don't have anything
>>>to say for a while.
>>>
>>>Looking forward to test the grouping also!
>>>
>>>/Robert
>>>
>>>      
>>>
>>>>/Robert
>>>>
>>>>        
>>>>
>>>>>I think there was a problem in Process() method in some states it was
>>>>>checking if the events fragment position is beyond the matrix while in
>>>>>some cases it wasn't. So i've made a change to always check that.
>>>>>I was getting a crash that may have been the same as yours but now i'm
>>>>>not getting it anymore. Our configs are different though (for one thing
>>>>>i was not using jack when i was getting those cores) so i'm not sure the
>>>>>root cause is the same . . . so please give it a try.
>>>>>
>>>>>Regards,
>>>>>Vladimir.
>>>>>
>>>>>Robert Jonsson wrote:
>>>>>          
>>>>>
>>>>>>On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote:
>>>>>>            
>>>>>>
>>>>>>>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson 
>>>>>>>              
>>>>>>>
>schrieb:
>  
>
>>>>>>>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable
>>>>>>>>though, optimized binary I presume, I will compile for debug later:
>>>>>>>>
>>>>>>>>(gdb) bt
>>>>>>>>#0  LinuxSampler::gig::EGADSR::Process(unsigned,
>>>>>>>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
>>>>>>>>(this=Variable "this" is not available.
>>>>>>>>) at EGADSR.cpp:151
>>>>>>>>                
>>>>>>>>
>>>>>>>Seems it went beyond the boundaries of the synthesis parameters matrix
>>>>>>>which resulted in a segfault of course. That one has to be
>>>>>>>investigated. You didn't change any important JACK setting while
>>>>>>>running it, did you? Because LS's JACK driver currently doesn't react
>>>>>>>on such changes.
>>>>>>>              
>>>>>>>
>>>>>>To my knowledge the only think I did was hitting keys on the
>>>>>>midi-keyboard.
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>As for drum specific things, it is common in drumbanks to have the
>>>>>>>>hihat on several keys (as is the case here too), since a hihat is
>>>>>>>>monophonic by nature these keys are often grouped together so only
>>>>>>>>one of them can produce sound at the time.
>>>>>>>>                
>>>>>>>>
>>>>>>>Yes, libgig reads and offers sample group informations (see gig.h,
>>>>>>>line 458), but these informations are not yet used by the gig engine.
>>>>>>>This is an important feature that has to be implemented.
>>>>>>>              
>>>>>>>
>>>>>>Ah, cool.
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>I noticed the ECHO ON in the script which is a good thing indeed.
>>>>>>>>Would it be possible to extend this to outputting text in the
>>>>>>>>terminal on the server side also?
>>>>>>>>I'm not sure if it's the right way to do it but I imagine it would be
>>>>>>>>quite usable for debugging when running the GUI and linuxsampler in
>>>>>>>>separate terminals. I would for sure have liked it while trying to
>>>>>>>>get the GUI to dance.
>>>>>>>>                
>>>>>>>>
>>>>>>>Agreed, could be quite handy for debugging the GUI.
>>>>>>>
>>>>>>>CU
>>>>>>>Christian
>>>>>>>
>>>>>>>P.S. sorry for the late response
>>>>>>>              
>>>>>>>
>>>>>>No problem at all.
>>>>>>
>>>>>>/Robert
>>>>>>            
>>>>>>
>>>>>-------------------------------------------------------
>>>>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>>>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>>>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>>>>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
>>>>>_______________________________________________
>>>>>Linuxsampler-devel mailing list
>>>>>Lin...@li...
>>>>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>>>>          
>>>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>_______________________________________________
>>Linuxsampler-devel mailing list
>>Lin...@li...
>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>    
>>
>
>  
>

Re: [Linuxsampler-devel] example LSCP scripts

[Robert J. <rj...@sp...>]

Hi guys,

tisdagen den 21 september 2004 23.04 skrev Vladimir Senkov:
> Hi Robert,
>
> Please make sure you're running the latest LS. I've made a check-in a
> few days ago that fixed a small problem with panning that caused LS to
> be silent. I'm hoping it's the same problem you have at the moment so
> things should be working again once you take an update from cvs.
> Sorry about that, bad timing :(

Actually I had updated the tree.
I had me a doze of inspiration and started poking at it again. And as it=20
happens I was trying the wrong startup script (I am curently not running=20
through the GUI)...sorry... I think I'm a little over worked ;)...

As for the crash bug, I haven't seen it... though I didn't play that long.=
=20
Seems solid enough.=20
I noticed the grouping has started to work also. Great! Atleast on some of =
the=20
samples. I have to check with that GIG utility what samples really are in t=
he=20
group, probably it's correct but I think there should be more of them.

Also, I have new headphones...don't know if it's that or if it's been there=
=20
all along but I'm starting to hear artifacts in the sound. Clicking at the=
=20
end of the samples... and some very strange sound when "shutting of" a long=
=20
sound with a short one (in a group). I will try to record some examples so=
=20
you can hear what I'm trying to describe. Not tonight though.

/Robert

> It is usually a good idea to visit the news page on the LS website to
> see if there were any recent updates to the code that might fix an issue
> (if you have any). We try to put descriptive notes there to make it
> easier to figure out if it's the same problem or not.
>
> Regards,
> Vladimir.
>
> Robert Jonsson wrote:
> >m=E5ndagen den 20 september 2004 20.33 skrev Robert Jonsson:
> >>Hi,
> >>
> >>s=F6ndagen den 12 september 2004 04.06 skrev Vladimir Senkov:
> >>>Hi Robert,
> >>>
> >>>I've just checked something in, could you try to reproduce this problem
> >>>with the latest cvs?
> >>
> >>Long response times here, sorry. I'll try to hammer away at this a bit
> >>tonight, will see what happens.
> >
> >Ack, bad times... I didn't even manage to get any sound at all. I've used
> > up my timeslice for a few more days so I will likely don't have anything
> > to say for a while.
> >
> >Looking forward to test the grouping also!
> >
> >/Robert
> >
> >>/Robert
> >>
> >>>I think there was a problem in Process() method in some states it was
> >>>checking if the events fragment position is beyond the matrix while in
> >>>some cases it wasn't. So i've made a change to always check that.
> >>>I was getting a crash that may have been the same as yours but now i'm
> >>>not getting it anymore. Our configs are different though (for one thing
> >>>i was not using jack when i was getting those cores) so i'm not sure t=
he
> >>>root cause is the same . . . so please give it a try.
> >>>
> >>>Regards,
> >>>Vladimir.
> >>>
> >>>Robert Jonsson wrote:
> >>>>On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote:
> >>>>>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson=20
schrieb:
> >>>>>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable
> >>>>>>though, optimized binary I presume, I will compile for debug later:
> >>>>>>
> >>>>>>(gdb) bt
> >>>>>>#0  LinuxSampler::gig::EGADSR::Process(unsigned,
> >>>>>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
> >>>>>>(this=3DVariable "this" is not available.
> >>>>>>) at EGADSR.cpp:151
> >>>>>
> >>>>>Seems it went beyond the boundaries of the synthesis parameters matr=
ix
> >>>>>which resulted in a segfault of course. That one has to be
> >>>>>investigated. You didn't change any important JACK setting while
> >>>>>running it, did you? Because LS's JACK driver currently doesn't react
> >>>>>on such changes.
> >>>>
> >>>>To my knowledge the only think I did was hitting keys on the
> >>>>midi-keyboard.
> >>>>
> >>>>>>As for drum specific things, it is common in drumbanks to have the
> >>>>>>hihat on several keys (as is the case here too), since a hihat is
> >>>>>>monophonic by nature these keys are often grouped together so only
> >>>>>>one of them can produce sound at the time.
> >>>>>
> >>>>>Yes, libgig reads and offers sample group informations (see gig.h,
> >>>>> line 458), but these informations are not yet used by the gig engin=
e.
> >>>>> This is an important feature that has to be implemented.
> >>>>
> >>>>Ah, cool.
> >>>>
> >>>>>>I noticed the ECHO ON in the script which is a good thing indeed.
> >>>>>>Would it be possible to extend this to outputting text in the
> >>>>>>terminal on the server side also?
> >>>>>>I'm not sure if it's the right way to do it but I imagine it would =
be
> >>>>>>quite usable for debugging when running the GUI and linuxsampler in
> >>>>>>separate terminals. I would for sure have liked it while trying to
> >>>>>> get the GUI to dance.
> >>>>>
> >>>>>Agreed, could be quite handy for debugging the GUI.
> >>>>>
> >>>>>CU
> >>>>>Christian
> >>>>>
> >>>>>P.S. sorry for the late response
> >>>>
> >>>>No problem at all.
> >>>>
> >>>>/Robert
> >>>
> >>>-------------------------------------------------------
> >>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> >>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
> >>>who ports your project to Linux PPC the best. Sponsored by IBM.
> >>>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> >>>_______________________________________________
> >>>Linuxsampler-devel mailing list
> >>>Lin...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

=2D-=20
http://spamatica.se/music/

Re: [Linuxsampler-devel] example LSCP scripts

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

Hi Robert,

Please make sure you're running the latest LS. I've made a check-in a 
few days ago that fixed a small problem with panning that caused LS to 
be silent. I'm hoping it's the same problem you have at the moment so 
things should be working again once you take an update from cvs.
Sorry about that, bad timing :(
It is usually a good idea to visit the news page on the LS website to 
see if there were any recent updates to the code that might fix an issue 
(if you have any). We try to put descriptive notes there to make it 
easier to figure out if it's the same problem or not.

Regards,
Vladimir.

Robert Jonsson wrote:

>måndagen den 20 september 2004 20.33 skrev Robert Jonsson:
>  
>
>>Hi,
>>
>>söndagen den 12 september 2004 04.06 skrev Vladimir Senkov:
>>    
>>
>>>Hi Robert,
>>>
>>>I've just checked something in, could you try to reproduce this problem
>>>with the latest cvs?
>>>      
>>>
>>Long response times here, sorry. I'll try to hammer away at this a bit
>>tonight, will see what happens.
>>    
>>
>
>Ack, bad times... I didn't even manage to get any sound at all. I've used up 
>my timeslice for a few more days so I will likely don't have anything to say 
>for a while.
>
>Looking forward to test the grouping also!
>
>/Robert
>
>  
>
>>/Robert
>>
>>    
>>
>>>I think there was a problem in Process() method in some states it was
>>>checking if the events fragment position is beyond the matrix while in
>>>some cases it wasn't. So i've made a change to always check that.
>>>I was getting a crash that may have been the same as yours but now i'm
>>>not getting it anymore. Our configs are different though (for one thing
>>>i was not using jack when i was getting those cores) so i'm not sure the
>>>root cause is the same . . . so please give it a try.
>>>
>>>Regards,
>>>Vladimir.
>>>
>>>Robert Jonsson wrote:
>>>      
>>>
>>>>On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote:
>>>>        
>>>>
>>>>>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb:
>>>>>          
>>>>>
>>>>>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable
>>>>>>though, optimized binary I presume, I will compile for debug later:
>>>>>>
>>>>>>(gdb) bt
>>>>>>#0  LinuxSampler::gig::EGADSR::Process(unsigned,
>>>>>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
>>>>>>(this=Variable "this" is not available.
>>>>>>) at EGADSR.cpp:151
>>>>>>            
>>>>>>
>>>>>Seems it went beyond the boundaries of the synthesis parameters matrix
>>>>>which resulted in a segfault of course. That one has to be
>>>>>investigated. You didn't change any important JACK setting while
>>>>>running it, did you? Because LS's JACK driver currently doesn't react
>>>>>on such changes.
>>>>>          
>>>>>
>>>>To my knowledge the only think I did was hitting keys on the
>>>>midi-keyboard.
>>>>
>>>>        
>>>>
>>>>>>As for drum specific things, it is common in drumbanks to have the
>>>>>>hihat on several keys (as is the case here too), since a hihat is
>>>>>>monophonic by nature these keys are often grouped together so only
>>>>>>one of them can produce sound at the time.
>>>>>>            
>>>>>>
>>>>>Yes, libgig reads and offers sample group informations (see gig.h, line
>>>>>458), but these informations are not yet used by the gig engine. This
>>>>>is an important feature that has to be implemented.
>>>>>          
>>>>>
>>>>Ah, cool.
>>>>
>>>>        
>>>>
>>>>>>I noticed the ECHO ON in the script which is a good thing indeed.
>>>>>>Would it be possible to extend this to outputting text in the
>>>>>>terminal on the server side also?
>>>>>>I'm not sure if it's the right way to do it but I imagine it would be
>>>>>>quite usable for debugging when running the GUI and linuxsampler in
>>>>>>separate terminals. I would for sure have liked it while trying to get
>>>>>>the GUI to dance.
>>>>>>            
>>>>>>
>>>>>Agreed, could be quite handy for debugging the GUI.
>>>>>
>>>>>CU
>>>>>Christian
>>>>>
>>>>>P.S. sorry for the late response
>>>>>          
>>>>>
>>>>No problem at all.
>>>>
>>>>/Robert
>>>>        
>>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>>who ports your project to Linux PPC the best. Sponsored by IBM.
>>>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
>>>_______________________________________________
>>>Linuxsampler-devel mailing list
>>>Lin...@li...
>>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>>      
>>>
>
>  
>

Re: [Linuxsampler-devel] example LSCP scripts

[Robert J. <rj...@sp...>]

m=E5ndagen den 20 september 2004 20.33 skrev Robert Jonsson:
> Hi,
>
> s=F6ndagen den 12 september 2004 04.06 skrev Vladimir Senkov:
> > Hi Robert,
> >
> > I've just checked something in, could you try to reproduce this problem
> > with the latest cvs?
>
> Long response times here, sorry. I'll try to hammer away at this a bit
> tonight, will see what happens.

Ack, bad times... I didn't even manage to get any sound at all. I've used u=
p=20
my timeslice for a few more days so I will likely don't have anything to sa=
y=20
for a while.

Looking forward to test the grouping also!

/Robert

>
> /Robert
>
> > I think there was a problem in Process() method in some states it was
> > checking if the events fragment position is beyond the matrix while in
> > some cases it wasn't. So i've made a change to always check that.
> > I was getting a crash that may have been the same as yours but now i'm
> > not getting it anymore. Our configs are different though (for one thing
> > i was not using jack when i was getting those cores) so i'm not sure the
> > root cause is the same . . . so please give it a try.
> >
> > Regards,
> > Vladimir.
> >
> > Robert Jonsson wrote:
> > >On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote:
> > >>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schri=
eb:
> > >>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable
> > >>>though, optimized binary I presume, I will compile for debug later:
> > >>>
> > >>>(gdb) bt
> > >>>#0  LinuxSampler::gig::EGADSR::Process(unsigned,
> > >>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
> > >>>(this=3DVariable "this" is not available.
> > >>>) at EGADSR.cpp:151
> > >>
> > >>Seems it went beyond the boundaries of the synthesis parameters matrix
> > >>which resulted in a segfault of course. That one has to be
> > >> investigated. You didn't change any important JACK setting while
> > >> running it, did you? Because LS's JACK driver currently doesn't react
> > >> on such changes.
> > >
> > >To my knowledge the only think I did was hitting keys on the
> > > midi-keyboard.
> > >
> > >>>As for drum specific things, it is common in drumbanks to have the
> > >>> hihat on several keys (as is the case here too), since a hihat is
> > >>> monophonic by nature these keys are often grouped together so only
> > >>> one of them can produce sound at the time.
> > >>
> > >>Yes, libgig reads and offers sample group informations (see gig.h, li=
ne
> > >>458), but these informations are not yet used by the gig engine. This
> > >> is an important feature that has to be implemented.
> > >
> > >Ah, cool.
> > >
> > >>>I noticed the ECHO ON in the script which is a good thing indeed.
> > >>> Would it be possible to extend this to outputting text in the
> > >>> terminal on the server side also?
> > >>>I'm not sure if it's the right way to do it but I imagine it would be
> > >>>quite usable for debugging when running the GUI and linuxsampler in
> > >>>separate terminals. I would for sure have liked it while trying to g=
et
> > >>>the GUI to dance.
> > >>
> > >>Agreed, could be quite handy for debugging the GUI.
> > >>
> > >>CU
> > >>Christian
> > >>
> > >>P.S. sorry for the late response
> > >
> > >No problem at all.
> > >
> > >/Robert
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

=2D-=20
http://spamatica.se/music/

Re: [Linuxsampler-devel] hidden docs?

[Christian S. <sch...@so...>]

Es geschah am Montag 20 September 2004 21:47 als Juhana Sadeharju schrieb:
> Hello.
> What else the docs dir contains?
>   http://www.linuxsampler.org/doc/engines/gig/EGADSR.pdf
> None of the subdirs are downloadable, and I don't want guess.
> Please open the doc/ subdir so that the whole hierarchy can be
> downloaded. Info about such subdir can be kept within us
> who are in this mailing list, if you wish so.

All directories are already world-rx, so it must be a paranoid Apache setting. 
Only Benno has shell access to that machine, so I can't do anything about it, 
sorry!

Beside the EGADSR transition diagram, these are currently only these files 
below the /doc directory:

http://www.linuxsampler.org/doc/InstrumentResourceManager.dpd
http://www.linuxsampler.org/doc/InstrumentResourceManager.pdf

So nothing really interesting ATM anyway. But I'm going to write a bunch of 
docs as soon as LS's voice stealing algorithm is stable. These docs will then 
all be available via CVS, too:

http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/Documentation/

CU
Christian

[Linuxsampler-devel] hidden docs?

[Juhana S. <ko...@ni...>]

Hello.
What else the docs dir contains?
  http://www.linuxsampler.org/doc/engines/gig/EGADSR.pdf
None of the subdirs are downloadable, and I don't want guess.
Please open the doc/ subdir so that the whole hierarchy can be
downloaded. Info about such subdir can be kept within us
who are in this mailing list, if you wish so.

It is always a good idea to keep dev docs available, e.g.,
for those who want to write their own sampler.

Juhana
-- 
  http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
  for developers of open source graphics software

Re: [Linuxsampler-devel] example LSCP scripts

[Robert J. <rj...@sp...>]

Hi,

s=F6ndagen den 12 september 2004 04.06 skrev Vladimir Senkov:
> Hi Robert,
>
> I've just checked something in, could you try to reproduce this problem
> with the latest cvs?

Long response times here, sorry. I'll try to hammer away at this a bit=20
tonight, will see what happens.

/Robert

> I think there was a problem in Process() method in some states it was
> checking if the events fragment position is beyond the matrix while in
> some cases it wasn't. So i've made a change to always check that.
> I was getting a crash that may have been the same as yours but now i'm
> not getting it anymore. Our configs are different though (for one thing
> i was not using jack when i was getting those cores) so i'm not sure the
> root cause is the same . . . so please give it a try.
>
> Regards,
> Vladimir.
>
> Robert Jonsson wrote:
> >On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote:
> >>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb:
> >>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable
> >>>though, optimized binary I presume, I will compile for debug later:
> >>>
> >>>(gdb) bt
> >>>#0  LinuxSampler::gig::EGADSR::Process(unsigned,
> >>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
> >>>(this=3DVariable "this" is not available.
> >>>) at EGADSR.cpp:151
> >>
> >>Seems it went beyond the boundaries of the synthesis parameters matrix
> >>which resulted in a segfault of course. That one has to be investigated.
> >>You didn't change any important JACK setting while running it, did you?
> >>Because LS's JACK driver currently doesn't react on such changes.
> >
> >To my knowledge the only think I did was hitting keys on the
> > midi-keyboard.
> >
> >>>As for drum specific things, it is common in drumbanks to have the hih=
at
> >>>on several keys (as is the case here too), since a hihat is monophonic
> >>> by nature these keys are often grouped together so only one of them c=
an
> >>> produce sound at the time.
> >>
> >>Yes, libgig reads and offers sample group informations (see gig.h, line
> >>458), but these informations are not yet used by the gig engine. This is
> >> an important feature that has to be implemented.
> >
> >Ah, cool.
> >
> >>>I noticed the ECHO ON in the script which is a good thing indeed. Would
> >>>it be possible to extend this to outputting text in the terminal on the
> >>>server side also?
> >>>I'm not sure if it's the right way to do it but I imagine it would be
> >>>quite usable for debugging when running the GUI and linuxsampler in
> >>>separate terminals. I would for sure have liked it while trying to get
> >>>the GUI to dance.
> >>
> >>Agreed, could be quite handy for debugging the GUI.
> >>
> >>CU
> >>Christian
> >>
> >>P.S. sorry for the late response
> >
> >No problem at all.
> >
> >/Robert
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

=2D-=20
http://spamatica.se/music/

Re: [Linuxsampler-devel] Gigasampler and Key Groups

[Christian S. <sch...@so...>]

Es geschah am Sonntag 12 September 2004 00:59 als Sebastien Metrot schrieb:
> What you call keygroups is usualy refered to as exclusive groups. What

Yeah, but AFAIK in the Gigasampler world it's called keygroups. Probably 
because the gig Format only allows a key to have one region, unlike e.g. the 
DLS format which allows several regions for the same key.

> you have to do is to simply kill the currently playing voice of an
> exclusive group when the user starts playing a new voice on the same
> group. (Of course you have to take care of the potential click and fade
> out the rendering). You can picture this as a monophonic sub layer
> inside a layer...

Ok, already guessed that, just wanted to be sure. Thanks!
I commited it to CVS minutes ago.

Es geschah am Sonntag 12 September 2004 04:09 als Vladimir Senkov schrieb:
> I think we have already discussed this topic of "simply killing" the
> voice back when we were talking about voice stealing.
> Is it just a quick release and if so where do we get timing parameters
> for it? Any ideas?

I simply use a very quick exponential fade down (see 
EGADSR::CalculateEndCoeff()) and every state can now immediately transit to 
the 'end_stage' which actually does the quick fade down (btw, we have to kill 
denormals there, I forgot to do that). Here the latest state diagram:

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

> Can the same mechanism be used for voice stealing?

You can use the new Voice::Kill() method to kill a voice (e.g. for voice 
stealing). It takes care of the fade down (to avoid clicks) and processing 
until the kill event actually occured.

CU
Christian

Re: [Linuxsampler-devel] Gigasampler and Key Groups

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

Guys,

I think we have already discussed this topic of "simply killing" the 
voice back when we were talking about voice stealing.
Is it just a quick release and if so where do we get timing parameters 
for it? Any ideas?
Can the same mechanism be used for voice stealing?

Regards,
Vladimir.

Sebastien Metrot wrote:

> Hi Christian :-)
>
> What you call keygroups is usualy refered to as exclusive groups. What 
> you have to do is to simply kill the currently playing voice of an 
> exclusive group when the user starts playing a new voice on the same 
> group. (Of course you have to take care of the potential click and 
> fade out the rendering). You can picture this as a monophonic sub 
> layer inside a layer...
>
> Sebastien
>
>
> Christian Schoenebeck wrote:
>
>> Hi!
>>
>> I started to implement key groups (important for drum patches and 
>> monophonic instruments) in LS today, but it seems I haven't 
>> understood completely Gigasampler's concept regarding keygroups yet.
>>
>> I implemented it that way today: if a key is triggered then I'll 
>> check if there's another key active in the same key group and if so I 
>> trigger the release process of the voices on the other key. Now I 
>> tested it with the free natural studio drumkit:
>>
>> http://www.naturalstudio.co.uk/ns_kit.html
>>
>> and it sounds like the key group mechanism isn't working at all; 
>> reason: the hihats (which use the key group feature) usually use a 
>> very, very long release time. So the question is, should I simply 
>> override the official release time when I release a voice due to a 
>> keygroup conflict? If yes what release time should I use? I simply 
>> can't find additional patch informations for this in the gig format. 
>> Maybe I have overlooked something?
>>
>> I'd appreciate If somebody could enlighten me!
>>
>> CU
>> Christian
>>
>>
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] example LSCP scripts

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

Hi Robert,

I've just checked something in, could you try to reproduce this problem 
with the latest cvs?
I think there was a problem in Process() method in some states it was 
checking if the events fragment position is beyond the matrix while in 
some cases it wasn't. So i've made a change to always check that.
I was getting a crash that may have been the same as yours but now i'm 
not getting it anymore. Our configs are different though (for one thing 
i was not using jack when i was getting those cores) so i'm not sure the 
root cause is the same . . . so please give it a try.

Regards,
Vladimir.

Robert Jonsson wrote:

>On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote:
>  
>
>>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb:
>>    
>>
>>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable
>>>though, optimized binary I presume, I will compile for debug later:
>>>
>>>(gdb) bt
>>>#0  LinuxSampler::gig::EGADSR::Process(unsigned,
>>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
>>>(this=Variable "this" is not available.
>>>) at EGADSR.cpp:151
>>>      
>>>
>>Seems it went beyond the boundaries of the synthesis parameters matrix
>>which resulted in a segfault of course. That one has to be investigated.
>>You didn't change any important JACK setting while running it, did you?
>>Because LS's JACK driver currently doesn't react on such changes.
>>    
>>
>
>To my knowledge the only think I did was hitting keys on the midi-keyboard.
>
>  
>
>>>As for drum specific things, it is common in drumbanks to have the hihat
>>>on several keys (as is the case here too), since a hihat is monophonic by
>>>nature these keys are often grouped together so only one of them can
>>>produce sound at the time.
>>>      
>>>
>>Yes, libgig reads and offers sample group informations (see gig.h, line
>>458), but these informations are not yet used by the gig engine. This is an
>>important feature that has to be implemented.
>>    
>>
>
>Ah, cool.
>
>  
>
>>>I noticed the ECHO ON in the script which is a good thing indeed. Would
>>>it be possible to extend this to outputting text in the terminal on the
>>>server side also?
>>>I'm not sure if it's the right way to do it but I imagine it would be
>>>quite usable for debugging when running the GUI and linuxsampler in
>>>separate terminals. I would for sure have liked it while trying to get
>>>the GUI to dance.
>>>      
>>>
>>Agreed, could be quite handy for debugging the GUI.
>>
>>CU
>>Christian
>>
>>P.S. sorry for the late response
>>    
>>
>
>No problem at all.
>
>/Robert
>
>
>  
>

Re: [Linuxsampler-devel] Gigasampler and Key Groups

[Sebastien M. <me...@me...>]

Hi Christian :-)

What you call keygroups is usualy refered to as exclusive groups. What 
you have to do is to simply kill the currently playing voice of an 
exclusive group when the user starts playing a new voice on the same 
group. (Of course you have to take care of the potential click and fade 
out the rendering). You can picture this as a monophonic sub layer 
inside a layer...

Sebastien


Christian Schoenebeck wrote:

>Hi!
>
>I started to implement key groups (important for drum patches and monophonic 
>instruments) in LS today, but it seems I haven't understood completely 
>Gigasampler's concept regarding keygroups yet.
>
>I implemented it that way today: if a key is triggered then I'll check if 
>there's another key active in the same key group and if so I trigger the 
>release process of the voices on the other key. Now I tested it with the free 
>natural studio drumkit:
>
> http://www.naturalstudio.co.uk/ns_kit.html
>
>and it sounds like the key group mechanism isn't working at all; reason: the 
>hihats (which use the key group feature) usually use a very, very long 
>release time. So the question is, should I simply override the official 
>release time when I release a voice due to a keygroup conflict? If yes what 
>release time should I use? I simply can't find additional patch informations 
>for this in the gig format. Maybe I have overlooked something?
>
>I'd appreciate If somebody could enlighten me!
>
>CU
>Christian
>
> 
>  
>

[Linuxsampler-devel] Gigasampler and Key Groups

[Christian S. <sch...@so...>]

Hi!

I started to implement key groups (important for drum patches and monophonic 
instruments) in LS today, but it seems I haven't understood completely 
Gigasampler's concept regarding keygroups yet.

I implemented it that way today: if a key is triggered then I'll check if 
there's another key active in the same key group and if so I trigger the 
release process of the voices on the other key. Now I tested it with the free 
natural studio drumkit:

 http://www.naturalstudio.co.uk/ns_kit.html

and it sounds like the key group mechanism isn't working at all; reason: the 
hihats (which use the key group feature) usually use a very, very long 
release time. So the question is, should I simply override the official 
release time when I release a voice due to a keygroup conflict? If yes what 
release time should I use? I simply can't find additional patch informations 
for this in the gig format. Maybe I have overlooked something?

I'd appreciate If somebody could enlighten me!

CU
Christian

 

[Linuxsampler-devel] Re: multi threading (was: GSt3 is out - does not support multiple)

[<le...@rd...>]

On 5 sept. 04, at 12:08, Christian Schoenebeck wrote:

> Es geschah am Sonntag, 5. September 2004 07:59 als St=E9phane LETZ=20
> schrieb:
>> But this solution requite LS to implement its own thread management
>> code? I mean LS would create supplementary threads by itself and the
>> Jack callback would have to wait for  the internal thread to finish?
>
> No the JACK client thread would not wait. If not all jobs are done=20
> yet, than
> it would pick up a free job by itself instead of just waiting for the=20=

> other
> threads to finish.

OK. Actually it was already clear in you previous mail.. that I did not=20=

read carefully enough....

>
>> I think all this thread management can be done by Jack itself. After
>> having made this proposition of 2 Jack clients, I think now that a
>> model with only one *single* Jack client with several Audio callback
>> would be better.
>> Basically the idea would be to extend Jack API to be able to=20
>> add/remove
>> several Audio callbacks. Then each thread does its jobs the way you
>> describe, and the Jack client wait for  the 2 threads to finish. The
>> difference is that the  thread management (setting the correct
>> parameter for the real-time for example)  is done by Jack which is
>> better.
>
> Sure, if you just use the JACK driver then you'll be fine. But there=20=

> will be
> many other audio drivers for LS and which of them support multi=20
> threading on
> their side? So nothing against the multi threading approach on JACKs=20=

> side,
> but we need a general, driver independent solution one day anyway.

Sure.
But in a more general point of view I think adding multi threading=20
capabilities in one application (to take profit of multi-processors)=20
without taking account of the outside context the application will run=20=

in, have some inherent limitations.

What happens if a multi threaded LS runs on a machine where other audio=20=

applictions are also competing for the available processors? At some=20
point having too much real-time threads competing is worse that having=20=

less threads.
Basically they will not be able to run at the same time and you may=20
have aditionnal cost like more context-switches for example.

The strengh of the Jack based approach, where *all* audio applications=20=

run under the control of the jack server, is that the server can have a=20=

global view of all running applications. Depending of the connection=20
topology between applications, the server could for example estimate if=20=

there will be two much threads competing for the available number of=20
processors  in one part of the client graph. And possibly notify=20
clients so that they can adapt to the situation dynamically.

These are some vague ideas (that are not part of the jack sever=20
yet...), but I'm sure this is something to further explore for the Jack=20=

server muti-processors version.

Stephane

[Linuxsampler-devel] multi threading (was: GSt3 is out - does not support multiple)

[Christian S. <sch...@so...>]

Es geschah am Sonntag, 5. September 2004 07:59 als St=E9phane LETZ schrieb:
> But this solution requite LS to implement its own thread management
> code? I mean LS would create supplementary threads by itself and the
> Jack callback would have to wait for  the internal thread to finish?

No the JACK client thread would not wait. If not all jobs are done yet, tha=
n=20
it would pick up a free job by itself instead of just waiting for the other=
=20
threads to finish.

> I think all this thread management can be done by Jack itself. After
> having made this proposition of 2 Jack clients, I think now that a
> model with only one *single* Jack client with several Audio callback
> would be better.
> Basically the idea would be to extend Jack API to be able to add/remove
> several Audio callbacks. Then each thread does its jobs the way you
> describe, and the Jack client wait for  the 2 threads to finish. The
> difference is that the  thread management (setting the correct
> parameter for the real-time for example)  is done by Jack which is
> better.

Sure, if you just use the JACK driver then you'll be fine. But there will b=
e=20
many other audio drivers for LS and which of them support multi threading o=
n=20
their side? So nothing against the multi threading approach on JACKs side,=
=20
but we need a general, driver independent solution one day anyway.

CU
Christian

[Linuxsampler-devel] Re: GSt3 is out - does not support multiple

[<le...@rd...>]

>
>
> --__--__--
>
> Message: 3
> From: Robert Jonsson <rj...@sp...>
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Re: GSt3 is out - does not support 
> multiple
> Date: Sat, 4 Sep 2004 13:46:01 +0200
>
> l=F6rdagen den 4 september 2004 09.23 skrev St=E9phane LETZ:
>>> Message: 1
>>> Date: Fri, 03 Sep 2004 06:57:39 -0700
>>> From: Mark Knecht <mk...@co...>
>>> To: Linux-Sampler <lin...@li...>
>>> Subject: Re: [Linuxsampler-devel] GSt3 is out - does not support
>>> multiple
>>>  processors
>>>
>>> Mark Knecht wrote:
>>>> Apparently is doesn't run on a multi-processor box, and if you have 
>>>> a
>>>> hyper-threading P4 you have to turn that off.
>>>>
>>>> Hey - another opportunity for LS!
>>>>
>>>> - Mark
>>
>> I'm working on a multi-processors version of Jack. Would it be a way 
>> to
>> add  multi-processors  support to LS?
>> For example if LS would be able to run multiple audio engines driven 
>> by
>> multiple jack clients, then LS could be multi-processors !
>
> Sounds very interesting!=20
>
> As I understand it the common view is that multiprocessing and 
> lowlatency d=
> o=20
> not match.

Why?

> But you think there is a way?=20

I have a Jack multi-processor version on MacOSX that run very well! At 
64 frames without problems on a dual 1.8 Ghz G5.

Basically there is no fundamental difference in having several Audio 
clients (like CoreAudio clients for example) running together on a 
machine (a setup that you can perfectly done on MacOSX with regular 
applications) and the Jack for multi-processor model.


> Having it in jack sounds almost too good to be true ;). It would mean 
> that=
> =20
> different client could run in different threads, on different CPUs, as 
> long=
> =20
> as their graphs are parallell right?=20

Exactly! This is the idea.

The activation model is now more  a "data-flow" model. Each client 
maintains a input dependency counter (the number of input client it 
depends on)
and clients are made runnable (and thus possibly executed on the first 
available processor) as soon as all their input clients have been 
runned.

Stephane

[Linuxsampler-devel] Re: GSt3 is out - does not support multiple

[<le...@rd...>]

>
> Es geschah am Samstag, 4. September 2004 09:23 als St=E9phane LETZ 
> schrieb:
>> I'm working on a multi-processors version of Jack. Would it be a way 
>> to
>> add  multi-processors  support to LS?
>> For example if LS would be able to run multiple audio engines driven 
>> by
>> multiple jack clients, then LS could be multi-processors !
>>
>> How difficult would it be to have a multiple audio engine model in the
>> current version in order to test this idea?
>
> Each engine on each sampler channel is independent already. The thread 
> /=20
> process context solely comes from the audio output device (=3Ddriver) 
> the=20
> respective engine is connected to. So you would only have to modify 
> the JAC=
> K=20
> driver in LS a bit to be able to test it.
>
> But I wonder if it wouldn't be better to implement a driver 
> independent=20
> solution. Because copying the audio data to the final driver output 
> buffer=
> =20
> doesnt take much CPU time. Most of the CPU time is used for rendering 
> the=20
> data in each engine. So I would propose to implement a job dispatcher 
> in th=
> e=20
> AudioOutputDevice base class which distributes jobs for calling 
> threads. So=
> =20
> there would be a fix number of threads (which can be set by the user) 
> which=
> =20
> just poll the AudioOutputDevice base class for scheduled render jobs 
> and th=
> e=20
> driver thread itself asks the AudioOutputDevice class if all jobs are 
> alrea=
> dy=20
> done, if not it will also take a free job and poll again if all jobs 
> are=20
> done. Finally when all jobs are done, the driver thread will just copy 
> the=
> =20
> audio data to the driver output buffer.
>
> Anyway, no matter what you do, please wait a bit til committing 
> something l=
> ike=20
> that to CVS. I'm currently working to get things stable for the 
> first=20
> release.
>
> CU
> Christian

But this solution requite LS to implement its own thread management 
code? I mean LS would create supplementary threads by itself and the 
Jack callback would have to wait for  the internal thread to finish?

I think all this thread management can be done by Jack itself. After 
having made this proposition of 2 Jack clients, I think now that a 
model with only one *single* Jack client with several Audio callback 
would be better.
Basically the idea would be to extend Jack API to be able to add/remove 
several Audio callbacks. Then each thread does its jobs the way you 
describe, and the Jack client wait for  the 2 threads to finish. The 
difference is that the  thread management (setting the correct 
parameter for the real-time for example)  is done by Jack which is 
better.

Moreover having the Jack client manage multi-threading alows the Jack 
server to possibly knows how many threads are used by each client, 
which may be of importance (for example each you have a Jack client 
graph where each client is multi-threading itself, at some point it is 
useless to have two many threads, that is more threads in parallel  
than the number processors available.)

And having one Jack cleint with several theads is better than having 2 
jack clients, because 2  jack client appears are separate entities for 
connection for example.

Stephane

[Linuxsampler-devel] bug report

[Robert J. <rj...@sp...>]

Hi,

I thought I'd report while I remember it that I noticed a (probably trivial) 
problem with the jack driver.

I was going to load different gigs and put them on different output ports 
towards jack. But it wouldn't let me, jack claimed the port was already 
created. 
As I understand it linuxsampler allows me to create an arbitrary number of 
outputs (DEVICES methinks?). But the name of the jack-port is probably 
hardcoded so the second port won't be instantiated correctly. Easiest way to 
fix is probably to add a counter to the name.

Another thing that happened a while ago was these error messages:

No unused stream found (OrderID:1) - report if this happens, this is a bug!
No unused stream found (OrderID:2) - report if this happens, this is a bug!
0x404508e0Disk stream not available in time!
No unused stream found (OrderID:8) - report if this happens, this is a bug!
0x404508e0Disk stream not available in time!
0x404508e0Disk stream not available in time!

I was just jamming along, not sure if it was audible, after a while it 
disappeared. No crashes during this as I recall. 
Nothing conclusive, sorry.

/Robert



-- 
http://spamatica.se/music/

Re: [Linuxsampler-devel] Re: GSt3 is out - does not support multiple

[Robert J. <rj...@sp...>]

l=F6rdagen den 4 september 2004 09.23 skrev St=E9phane LETZ:
> > Message: 1
> > Date: Fri, 03 Sep 2004 06:57:39 -0700
> > From: Mark Knecht <mk...@co...>
> > To: Linux-Sampler <lin...@li...>
> > Subject: Re: [Linuxsampler-devel] GSt3 is out - does not support
> > multiple
> >  processors
> >
> > Mark Knecht wrote:
> >> Apparently is doesn't run on a multi-processor box, and if you have a
> >> hyper-threading P4 you have to turn that off.
> >>
> >> Hey - another opportunity for LS!
> >>
> >> - Mark
>
> I'm working on a multi-processors version of Jack. Would it be a way to
> add  multi-processors  support to LS?
> For example if LS would be able to run multiple audio engines driven by
> multiple jack clients, then LS could be multi-processors !

Sounds very interesting!=20

As I understand it the common view is that multiprocessing and lowlatency d=
o=20
not match. But you think there is a way?=20
Having it in jack sounds almost too good to be true ;). It would mean that=
=20
different client could run in different threads, on different CPUs, as long=
=20
as their graphs are parallell right?=20
That would be a great feat indeed!=20
Though, at the moment I don't own any dual systems... it would have been gr=
eat=20
to try and help out...

/Robert

>
> How difficult would it be to have a multiple audio engine model in the
> current version in order to test this idea?
>
> Stephane
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

=2D-=20
http://spamatica.se/music/

Re: [Linuxsampler-devel] Re: GSt3 is out - does not support multiple

[Christian S. <sch...@so...>]

Es geschah am Samstag, 4. September 2004 09:23 als St=E9phane LETZ schrieb:
> I'm working on a multi-processors version of Jack. Would it be a way to
> add  multi-processors  support to LS?
> For example if LS would be able to run multiple audio engines driven by
> multiple jack clients, then LS could be multi-processors !
>
> How difficult would it be to have a multiple audio engine model in the
> current version in order to test this idea?

Each engine on each sampler channel is independent already. The thread /=20
process context solely comes from the audio output device (=3Ddriver) the=20
respective engine is connected to. So you would only have to modify the JAC=
K=20
driver in LS a bit to be able to test it.

But I wonder if it wouldn't be better to implement a driver independent=20
solution. Because copying the audio data to the final driver output buffer=
=20
doesnt take much CPU time. Most of the CPU time is used for rendering the=20
data in each engine. So I would propose to implement a job dispatcher in th=
e=20
AudioOutputDevice base class which distributes jobs for calling threads. So=
=20
there would be a fix number of threads (which can be set by the user) which=
=20
just poll the AudioOutputDevice base class for scheduled render jobs and th=
e=20
driver thread itself asks the AudioOutputDevice class if all jobs are alrea=
dy=20
done, if not it will also take a free job and poll again if all jobs are=20
done. Finally when all jobs are done, the driver thread will just copy the=
=20
audio data to the driver output buffer.

Anyway, no matter what you do, please wait a bit til committing something l=
ike=20
that to CVS. I'm currently working to get things stable for the first=20
release.

CU
Christian

[Linuxsampler-devel] Re: GSt3 is out - does not support multiple

[<le...@rd...>]

>
> Message: 1
> Date: Fri, 03 Sep 2004 06:57:39 -0700
> From: Mark Knecht <mk...@co...>
> To: Linux-Sampler <lin...@li...>
> Subject: Re: [Linuxsampler-devel] GSt3 is out - does not support 
> multiple
>  processors
>
> Mark Knecht wrote:
>> Apparently is doesn't run on a multi-processor box, and if you have a
>> hyper-threading P4 you have to turn that off.
>>
>> Hey - another opportunity for LS!
>>
>> - Mark
>>

I'm working on a multi-processors version of Jack. Would it be a way to 
add  multi-processors  support to LS?
For example if LS would be able to run multiple audio engines driven by 
multiple jack clients, then LS could be multi-processors !

How difficult would it be to have a multiple audio engine model in the 
current version in order to test this idea?

Stephane

Re: [Linuxsampler-devel] GSt3 is out - does not support multiple processors

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

Mark Knecht wrote:
> Apparently is doesn't run on a multi-processor box, and if you have a
> hyper-threading P4 you have to turn that off.
> 
> Hey - another opportunity for LS!
> 
> - Mark
> 
A bit more - supports VST but not VSTi and fails with XP SP2 (big deal - 
many things are!)

[Linuxsampler-devel] GSt3 is out - does not support multiple processors

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

Apparently is doesn't run on a multi-processor box, and if you have a
hyper-threading P4 you have to turn that off.

Hey - another opportunity for LS!

- Mark

Re: [Linuxsampler-devel] example LSCP scripts (was: trials)

[Robert J. <rj...@sp...>]

On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote:
> Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb:
> > Ahh, here's a backtrace of one of the crashes, seems mostly unusable
> > though, optimized binary I presume, I will compile for debug later:
> >
> > (gdb) bt
> > #0  LinuxSampler::gig::EGADSR::Process(unsigned,
> > RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
> > (this=Variable "this" is not available.
> > ) at EGADSR.cpp:151
>
> Seems it went beyond the boundaries of the synthesis parameters matrix
> which resulted in a segfault of course. That one has to be investigated.
> You didn't change any important JACK setting while running it, did you?
> Because LS's JACK driver currently doesn't react on such changes.

To my knowledge the only think I did was hitting keys on the midi-keyboard.

>
> > As for drum specific things, it is common in drumbanks to have the hihat
> > on several keys (as is the case here too), since a hihat is monophonic by
> > nature these keys are often grouped together so only one of them can
> > produce sound at the time.
>
> Yes, libgig reads and offers sample group informations (see gig.h, line
> 458), but these informations are not yet used by the gig engine. This is an
> important feature that has to be implemented.

Ah, cool.

>
> > I noticed the ECHO ON in the script which is a good thing indeed. Would
> > it be possible to extend this to outputting text in the terminal on the
> > server side also?
> > I'm not sure if it's the right way to do it but I imagine it would be
> > quite usable for debugging when running the GUI and linuxsampler in
> > separate terminals. I would for sure have liked it while trying to get
> > the GUI to dance.
>
> Agreed, could be quite handy for debugging the GUI.
>
> CU
> Christian
>
> P.S. sorry for the late response

No problem at all.

/Robert


-- 
http://spamatica.se/music/

Re: [Linuxsampler-devel] example LSCP scripts (was: trials)

[Christian S. <sch...@so...>]

Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb:
> Ahh, here's a backtrace of one of the crashes, seems mostly unusable
> though, optimized binary I presume, I will compile for debug later:
>
> (gdb) bt
> #0  LinuxSampler::gig::EGADSR::Process(unsigned,
> RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)
> (this=Variable "this" is not available.
> ) at EGADSR.cpp:151

Seems it went beyond the boundaries of the synthesis parameters matrix which 
resulted in a segfault of course. That one has to be investigated. You didn't 
change any important JACK setting while running it, did you? Because LS's 
JACK driver currently doesn't react on such changes.

> As for drum specific things, it is common in drumbanks to have the hihat on
> several keys (as is the case here too), since a hihat is monophonic by
> nature these keys are often grouped together so only one of them can
> produce sound at the time.

Yes, libgig reads and offers sample group informations (see gig.h, line 458), 
but these informations are not yet used by the gig engine. This is an 
important feature that has to be implemented.

> I noticed the ECHO ON in the script which is a good thing indeed. Would it
> be possible to extend this to outputting text in the terminal on the server
> side also?
> I'm not sure if it's the right way to do it but I imagine it would be quite
> usable for debugging when running the GUI and linuxsampler in separate
> terminals. I would for sure have liked it while trying to get the GUI to
> dance.

Agreed, could be quite handy for debugging the GUI.

CU
Christian

P.S. sorry for the late response

Re: [Linuxsampler-devel] design ideas

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

th...@ho... wrote:
> Well i'veen thinking what to make 4 the qt skin, so i did a draft (mspaint) in 
> some sort of block diagram of what to put in there, here i would like especially 
> rui's feedback on what can and can´t be made (like the knobs for example, i 
> know i would like some reason like turning knobs, but the rotating effect its 
> not easy to make), height,width of each module,etc.
> the LCD i turned to blue, since i liked it better too :P
> 
> hope u all enjoy.
> 
> PS, the draft block diagram is at www.hocore.com.ar/imgz/draft.bmp
> 

I'm a big fan of MIDI activity information on each instance. Is the 
block receiving events, retransmitting events, etc., things like that. 
Nothing more than a single red light is a big help and usually enough to 
  show what's going on. In the case of LS possibly some clear indication 
of what MIDI channel each instance is using would also be good. That's 
pretty static and could be in the LCD.

- Mark