Menu
▾
▴
linuxsampler-devel
|
From: Vladimir S. <ha...@so...> - 2004-01-18 22:03:58
Attachments:
adsdr5.gz
|
Mark, Christian has just checked things into cvs and now eg code has changed a little. I've merged the changes and here is a patch against the latest CVS. Regards, Vladimir. Mark Knecht wrote: >On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote: > > >>No, no chance of me not floodding this list today :( >>Left some debug in there . . . >>So here you go again. >> >> >> > >I must not be doing this correctly. This is against Christian's CVS >commit from today. > >bash-2.05b$ pwd >/home/mark/data/LinuxSampler >bash-2.05b$ cd linuxsampler >bash-2.05b$ ls >AUTHORS INSTALL README config.guess configure.in linuxsampler.kdevelop.pcs missing >COPYING Makefile.am acconfig.h config.h.in depcomp linuxsampler.kdevses mkinstalldirs >CVS Makefile.cvs aclocal.m4 config.sub install-sh ltconfig src >Doxyfile Makefile.in autom4te.cache configure linuxsampler.kdevelop ltmain.sh templates > > >bash-2.05b$ patch -p1 <../adsdr4 >patching file src/eg_vca.cpp >Hunk #2 FAILED at 97. >1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej >patching file src/eg_vca.h >Hunk #1 FAILED at 40. >1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej >patching file src/voice.cpp >bash-2.05b$ > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > |
|
From: Mark K. <mar...@co...> - 2004-01-18 22:13:47
|
Vladimir, Thanks. This seems to have patched correctly using patch -p1 <../adsdr5 Is there anything specific you want me to look for? I suppose I'll have to try out Christian's Jack support also. Thanks, Mark On Sun, 2004-01-18 at 14:02, Vladimir Senkov wrote: > Mark, > > Christian has just checked things into cvs and now eg code has changed a > little. > I've merged the changes and here is a patch against the latest CVS. > > Regards, > Vladimir. > > Mark Knecht wrote: > > >On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote: > > > > > >>No, no chance of me not floodding this list today :( > >>Left some debug in there . . . > >>So here you go again. > >> > >> > >> > > > >I must not be doing this correctly. This is against Christian's CVS > >commit from today. > > > >bash-2.05b$ pwd > >/home/mark/data/LinuxSampler > >bash-2.05b$ cd linuxsampler > >bash-2.05b$ ls > >AUTHORS INSTALL README config.guess configure.in linuxsampler.kdevelop.pcs missing > >COPYING Makefile.am acconfig.h config.h.in depcomp linuxsampler.kdevses mkinstalldirs > >CVS Makefile.cvs aclocal.m4 config.sub install-sh ltconfig src > >Doxyfile Makefile.in autom4te.cache configure linuxsampler.kdevelop ltmain.sh templates > > > > > >bash-2.05b$ patch -p1 <../adsdr4 > >patching file src/eg_vca.cpp > >Hunk #2 FAILED at 97. > >1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej > >patching file src/eg_vca.h > >Hunk #1 FAILED at 40. > >1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej > >patching file src/voice.cpp > >bash-2.05b$ > > > > > > > >------------------------------------------------------- > >The SF.Net email is sponsored by EclipseCon 2004 > >Premiere Conference on Open Tools Development and Integration > >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > >http://www.eclipsecon.org/osdn > >_______________________________________________ > >Linuxsampler-devel mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > > |
|
From: Vladimir S. <ha...@so...> - 2004-01-18 22:19:40
|
Mark, If you could try playing using different gigs. I only have a few and i'm sure there are going to be problems with some combinations of parameters . . . You should notice gigs without infinite sustain play differently now also try samples with post attack hold if you have those. Regards, Vladimir. PS: Jack support is great i'll play around with it as well. Mark Knecht wrote: >Vladimir, > Thanks. This seems to have patched correctly using > >patch -p1 <../adsdr5 > >Is there anything specific you want me to look for? I suppose I'll have >to try out Christian's Jack support also. > >Thanks, >Mark > >On Sun, 2004-01-18 at 14:02, Vladimir Senkov wrote: > > >>Mark, >> >>Christian has just checked things into cvs and now eg code has changed a >>little. >>I've merged the changes and here is a patch against the latest CVS. >> >>Regards, >>Vladimir. >> >>Mark Knecht wrote: >> >> >> >>>On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote: >>> >>> >>> >>> >>>>No, no chance of me not floodding this list today :( >>>>Left some debug in there . . . >>>>So here you go again. >>>> >>>> >>>> >>>> >>>> >>>I must not be doing this correctly. This is against Christian's CVS >>>commit from today. >>> >>>bash-2.05b$ pwd >>>/home/mark/data/LinuxSampler >>>bash-2.05b$ cd linuxsampler >>>bash-2.05b$ ls >>>AUTHORS INSTALL README config.guess configure.in linuxsampler.kdevelop.pcs missing >>>COPYING Makefile.am acconfig.h config.h.in depcomp linuxsampler.kdevses mkinstalldirs >>>CVS Makefile.cvs aclocal.m4 config.sub install-sh ltconfig src >>>Doxyfile Makefile.in autom4te.cache configure linuxsampler.kdevelop ltmain.sh templates >>> >>> >>>bash-2.05b$ patch -p1 <../adsdr4 >>>patching file src/eg_vca.cpp >>>Hunk #2 FAILED at 97. >>>1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej >>>patching file src/eg_vca.h >>>Hunk #1 FAILED at 40. >>>1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej >>>patching file src/voice.cpp >>>bash-2.05b$ >>> >>> >>> >>>------------------------------------------------------- >>>The SF.Net email is sponsored by EclipseCon 2004 >>>Premiere Conference on Open Tools Development and Integration >>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>>http://www.eclipsecon.org/osdn >>>_______________________________________________ >>>Linuxsampler-devel mailing list >>>Lin...@li... >>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >>> >>> >>> >>> >>> > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > |
|
From: Vladimir S. <ha...@so...> - 2004-01-19 01:23:40
Attachments:
adsdr6.gz
|
Mark, Last e-mail :) Few small things here but mostly to try out a hack to implement "re-sustain" effect we talked about earlier. For now, just a "proof of concept", it will be coded differently. for now i just created a global because there is no easy way to link sustain to voices after ProcessNoteOff(). Let me know how it feels with different samples. My impression is that it sounds fairly accurate with samples that have infinite sustain disabled (such as that free Steinway sample i'm using), but perhaps a bit too strong with infinite sustain samples such as Church Organ for example. I'm thinking about making that second sustain stage non-infinite just like decay2 even for samples with infinite sustain. Any thoughts on this? I'll test it with GS next weekend to see how it does it with different samples. Regards, Vladimir. PS: patch is not incremental. Apply to latest CVS. Mark Knecht wrote: >Vladimir, > Thanks. This seems to have patched correctly using > >patch -p1 <../adsdr5 > >Is there anything specific you want me to look for? I suppose I'll have >to try out Christian's Jack support also. > >Thanks, >Mark > >On Sun, 2004-01-18 at 14:02, Vladimir Senkov wrote: > > >>Mark, >> >>Christian has just checked things into cvs and now eg code has changed a >>little. >>I've merged the changes and here is a patch against the latest CVS. >> >>Regards, >>Vladimir. >> >>Mark Knecht wrote: >> >> >> >>>On Sun, 2004-01-18 at 12:20, Vladimir Senkov wrote: >>> >>> >>> >>> >>>>No, no chance of me not floodding this list today :( >>>>Left some debug in there . . . >>>>So here you go again. >>>> >>>> >>>> >>>> >>>> >>>I must not be doing this correctly. This is against Christian's CVS >>>commit from today. >>> >>>bash-2.05b$ pwd >>>/home/mark/data/LinuxSampler >>>bash-2.05b$ cd linuxsampler >>>bash-2.05b$ ls >>>AUTHORS INSTALL README config.guess configure.in linuxsampler.kdevelop.pcs missing >>>COPYING Makefile.am acconfig.h config.h.in depcomp linuxsampler.kdevses mkinstalldirs >>>CVS Makefile.cvs aclocal.m4 config.sub install-sh ltconfig src >>>Doxyfile Makefile.in autom4te.cache configure linuxsampler.kdevelop ltmain.sh templates >>> >>> >>>bash-2.05b$ patch -p1 <../adsdr4 >>>patching file src/eg_vca.cpp >>>Hunk #2 FAILED at 97. >>>1 out of 3 hunks FAILED -- saving rejects to file src/eg_vca.cpp.rej >>>patching file src/eg_vca.h >>>Hunk #1 FAILED at 40. >>>1 out of 1 hunk FAILED -- saving rejects to file src/eg_vca.h.rej >>>patching file src/voice.cpp >>>bash-2.05b$ >>> >>> >>> >>>------------------------------------------------------- >>>The SF.Net email is sponsored by EclipseCon 2004 >>>Premiere Conference on Open Tools Development and Integration >>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >>>http://www.eclipsecon.org/osdn >>>_______________________________________________ >>>Linuxsampler-devel mailing list >>>Lin...@li... >>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >>> >>> >>> >>> >>> > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > |
|
From: Mark K. <mar...@co...> - 2004-01-19 02:10:53
|
On Sun, 2004-01-18 at 17:22, Vladimir Senkov wrote: > Mark, > Last e-mail :) > > Few small things here but mostly to try out a hack to implement > "re-sustain" effect we talked about earlier. > For now, just a "proof of concept", it will be coded differently. for > now i just created a global because there is no easy way to link sustain > to voices after ProcessNoteOff(). > Let me know how it feels with different samples. My impression is that > it sounds fairly accurate with samples that have infinite sustain > disabled (such as that free Steinway sample i'm using), but perhaps a > bit too strong with infinite sustain samples such as Church Organ for > example. > I'm thinking about making that second sustain stage non-infinite just > like decay2 even for samples with infinite sustain. Any thoughts on this? > I'll test it with GS next weekend to see how it does it with different > samples. > > Regards, > Vladimir. > > PS: patch is not incremental. Apply to latest CVS. Vladimir & Christian, OK, I've installed today's CVS with ADSDR6. It seems to be working fine so far. It correctly determines if Jack is running. If Jack is not running it does what it did before. However, I needed to edit audioio.cpp before and what I needed to edit appears to have moved. Could I make my first simple enhancement request? Could we have a command line option to tell it which sound card to use? Earlier I was changing plughw:0 to plughw:1. Could the number be changed to be a command line option? (--card "plughw:1") If Jack is running it connects to the the Jack server, but it doesn't connect the audio path automatically. Could I make my second request to have a command line option to make this connection? (--jack-ch "playback_1, playback_2" - I.e. don't forget stereo vs. mono...) Also, I think it would be helpful to have LS print some sort of revision info when it starts. I have so many versions now I'd like to be sure when I install a new version that I'm really using it. ;-) OK, with that all behind me it appears that LS is working well with Jack. No clicks of pops so far. The only negative thing I've noticed so far is that with a lot of notes playing I seem to be getting a lot of hiss in the background. As the notes die away the hiss goes away, so it appears to be part of the sample, but in LS I *think* I'm getting a lot more hiss now? Could this be part of the ADSDR edit, or could it have something to do with using Jack? I need to go back and find the code that moved so that I can use my HDSP 9652 without Jack, or wait for you all to add the card choice enhancement. I'll start playing with more gigs and see what I come up with, but my first impression is very positive. Cheers, Mark |
|
From: Vladimir S. <ha...@so...> - 2004-01-31 02:58:05
|
Mark, Are you still getting hiss that you were getting before? If so, could you try to pull LS from CVS and rebuild and test if it is still there? If so, it may have something to do with jack support or other non-adsdr related changes. If you are only getting that after you apply adsdr patch then it must be something that came with the patch and i'll be happy to investigate. Any other feedback on that adsdr patch? I have a semi free weekend ahead and should be able to fix bugs or rewrite it completely depending on how bad it is :) Or maybe clean up the code and get it ready for check in? If anyone has time to review the code that would be greately appreciated. Also, if there are no objections, i could look into those enhancement requests that Mark made at the bottom of the e-mail. Should be pretty straight forward i assume, but i don't want to do that if someone is already looking into it :) Regards, Vladimir. Mark Knecht wrote: >On Sun, 2004-01-18 at 17:22, Vladimir Senkov wrote: > > >>Mark, >>Last e-mail :) >> >>Few small things here but mostly to try out a hack to implement >>"re-sustain" effect we talked about earlier. >>For now, just a "proof of concept", it will be coded differently. for >>now i just created a global because there is no easy way to link sustain >>to voices after ProcessNoteOff(). >>Let me know how it feels with different samples. My impression is that >>it sounds fairly accurate with samples that have infinite sustain >>disabled (such as that free Steinway sample i'm using), but perhaps a >>bit too strong with infinite sustain samples such as Church Organ for >>example. >>I'm thinking about making that second sustain stage non-infinite just >>like decay2 even for samples with infinite sustain. Any thoughts on this? >>I'll test it with GS next weekend to see how it does it with different >>samples. >> >>Regards, >>Vladimir. >> >>PS: patch is not incremental. Apply to latest CVS. >> >> > >Vladimir & Christian, > OK, I've installed today's CVS with ADSDR6. It seems to be working >fine so far. It correctly determines if Jack is running. If Jack is not >running it does what it did before. However, I needed to edit >audioio.cpp before and what I needed to edit appears to have moved. >Could I make my first simple enhancement request? Could we have a >command line option to tell it which sound card to use? Earlier I was >changing plughw:0 to plughw:1. Could the number be changed to be a >command line option? (--card "plughw:1") > > If Jack is running it connects to the the Jack server, but it doesn't >connect the audio path automatically. Could I make my second request to >have a command line option to make this connection? (--jack-ch >"playback_1, playback_2" - I.e. don't forget stereo vs. mono...) > > Also, I think it would be helpful to have LS print some sort of >revision info when it starts. I have so many versions now I'd like to be >sure when I install a new version that I'm really using it. ;-) > > OK, with that all behind me it appears that LS is working well with >Jack. No clicks of pops so far. The only negative thing I've noticed so >far is that with a lot of notes playing I seem to be getting a lot of >hiss in the background. As the notes die away the hiss goes away, so it >appears to be part of the sample, but in LS I *think* I'm getting a lot >more hiss now? Could this be part of the ADSDR edit, or could it have >something to do with using Jack? > > I need to go back and find the code that moved so that I can use my >HDSP 9652 without Jack, or wait for you all to add the card choice >enhancement. > > I'll start playing with more gigs and see what I come up with, but my >first impression is very positive. > >Cheers, >Mark > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > |
|
From: Christian S. <chr...@ep...> - 2004-01-31 20:29:48
|
Es geschah am Samstag, 31. Januar 2004 03:56 als Vladimir Senkov schrieb: > Any other feedback on that adsdr patch? I have a semi free weekend ahead > and should be able to fix bugs or rewrite it completely depending on how > bad it is :) Or maybe clean up the code and get it ready for check in? > If anyone has time to review the code that would be greately appreciated. Vladimir, Mark: Is the EG patch already finished? Means does the EG act like the original Gst one? I'm currently busy, but I'll have a look at it next week if you think the patch is already complete. > Also, if there are no objections, i could look into those enhancement > requests that Mark made at the bottom of the e-mail. Should be pretty > straight forward i assume, but i don't want to do that if someone is > already looking into it :) You mean those command line options, right? If yes, I'd appreciate if you'll take that task. Rui: Sorry, I'm still working on some things in the engine, but I'll start with the bison network interface next week. CU Christian P.S. these delays on this list are really annoying, maybe we should move the mailing list away from sourceforge |
|
From: Vladimir S. <ha...@so...> - 2004-02-01 00:37:04
|
Christian, I *think* it is 99% done. Keep in mind my inexperience with digital audio software though. I'll clean it up this weekend and send you the result. I'm not 100% sure it acts exactly like Gst but i tried to follow your emails when implementing it. I've added an ascii diagram describing the state machine. So if you don't have time to review the code but could take a quick look at that diagram that'd be great. Because if fundamentals are wrong it will not be worth your time reviewing the code. I have a few questions . . . First one is about the "double sustain". Are we going to do that? If so, how . . . i've hacked that in using a global and it seems to work ok, but i'd like feedback on that. Second question is about post attack hold. I was going to use gig::Sample::SamplePeriod to calculate post attack hold period but it is only 32 bits and that's in nanoseconds. 32 bits seems way too short for nanoseconds. So i was not sure if i was missing something or not. Currently, the post attack hold period is calculated incorrectly but i'm going to fix it tonight or tomorrow at the latest. Last question is about Release coefficient calculation for samples without infinite sustain. I'm currently calculating it only once before the trigger(). Sustain level is used in that calculation. But if Decay2 has already lowered the level from sustain level, then the Release coefficient is not updated and will actually produce a shorter release phase. This sould not produce clicks because decay2 has already lowered the level (if it hasn't lowered it enough then release phase will be long enough). I can't find any document to clarify if that is correct interpretation or not. It makes sense, but if release phase must really be fixed in time regardless of when it starts in decay2 phase, then coefficient will need to be calculated before Release(), not before Trigger(). It's not a problem to do it that way, but i'm just not sure what is the right way. Mark has also reported getting some hiss and i was hoping we could troubleshoot that to figure out if that is related to adsdr patch or not. I have not noticed that on my setup. Unfortunately Mark is having some problems with alsa at the moment so we can't really troubleshoot this right now. I'm onto command line options. Regards, Vladimir. ----- Original Message ----- From: "Christian Schoenebeck" <chr...@ep...> To: "Vladimir Senkov" <ha...@fu...>; "Rui Nuno Capela" <rn...@rn...> Cc: <lin...@li...> Sent: Saturday, January 31, 2004 3:24 PM Subject: Re: [Linuxsampler-devel] ADSDR 6th try > Es geschah am Samstag, 31. Januar 2004 03:56 als Vladimir Senkov schrieb: > > Any other feedback on that adsdr patch? I have a semi free weekend ahead > > and should be able to fix bugs or rewrite it completely depending on how > > bad it is :) Or maybe clean up the code and get it ready for check in? > > If anyone has time to review the code that would be greately appreciated. > > Vladimir, Mark: Is the EG patch already finished? Means does the EG act like > the original Gst one? I'm currently busy, but I'll have a look at it next > week if you think the patch is already complete. > > > Also, if there are no objections, i could look into those enhancement > > requests that Mark made at the bottom of the e-mail. Should be pretty > > straight forward i assume, but i don't want to do that if someone is > > already looking into it :) > > You mean those command line options, right? If yes, I'd appreciate if you'll > take that task. > > Rui: Sorry, I'm still working on some things in the engine, but I'll start > with the bison network interface next week. > > CU > Christian > > P.S. these delays on this list are really annoying, maybe we should move the > mailing list away from sourceforge > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
|
From: Mark K. <mar...@co...> - 2004-01-31 20:30:47
|
On Fri, 2004-01-30 at 18:56, Vladimir Senkov wrote: > Mark, > > Are you still getting hiss that you were getting before? > If so, could you try to pull LS from CVS and rebuild and test if it is > still there? If so, it may have something to do with jack support or > other non-adsdr related changes. If you are only getting that after you > apply adsdr patch then it must be something that came with the patch and > i'll be happy to investigate. > > Any other feedback on that adsdr patch? I have a semi free weekend ahead > and should be able to fix bugs or rewrite it completely depending on how > bad it is :) Or maybe clean up the code and get it ready for check in? > If anyone has time to review the code that would be greately appreciated. > > Also, if there are no objections, i could look into those enhancement > requests that Mark made at the bottom of the e-mail. Should be pretty > straight forward i assume, but i don't want to do that if someone is > already looking into it :) > > Regards, > Vladimir. Vladimir, Hi. I don't know what's happening on my end, but downloading LS this morning and building it I seem to either get no sound at all, or I get sound but only after a while. I've had some updates on this machine, so maybe its a gcc/glibc issue. I don't know yet. The adsdr6 patch file applies cleanly against today's CVS. I then edit the code in alsaio.cpp to go to 1,0 instead of 0,0, then ./configure and make. The code starts, looks normal, sees Jack if I have it running, but I get no MIDI events into it even though kaconnect says it's hooked up. Sometimes after a while I see a burst of MIDI and a whole bunch of noise, but mostly nothing. I'll see if I can figure this out, but it may be beyond my limited skills. It appears that when this happens it is taking out either all of Alsa or my HDSP 9652 driver. After the problem occurs in LS I'm unable to do anythingwith audio without a reboot. Even stopping and restarting Alsa isn't working. Not a nice start to the day... Take care, Mark |
|
From: Vladimir S. <ha...@so...> - 2004-01-31 23:14:22
|
Mark, Sorry to hear about your troubles. Have you upgraded alsa since the last time everything was working ok? If so, could you try to go back to alsa that worked ok? What else may have changed? Last time you had LS running CVS had the same code as it had yesterday (i had it saved and did a diff yesterday) so there were no checkins yet and LS should work the same way it worked before. I think it must be something else . . . kernel, alsa, jack . . . Maybe it's worth trying witout jack? Could you tell me your kernel, alsa and jack versions? I could try that combination on my pc, but i have different hardware so it probably will not have the same problem. Regards, Vladimir. ----- Original Message ----- From: "Mark Knecht" <mar...@co...> To: <ha...@fu...> Cc: "Linux-Sampler" <lin...@li...> Sent: Saturday, January 31, 2004 3:29 PM Subject: Re: [Linuxsampler-devel] ADSDR 6th try > On Fri, 2004-01-30 at 18:56, Vladimir Senkov wrote: > > Mark, > > > > Are you still getting hiss that you were getting before? > > If so, could you try to pull LS from CVS and rebuild and test if it is > > still there? If so, it may have something to do with jack support or > > other non-adsdr related changes. If you are only getting that after you > > apply adsdr patch then it must be something that came with the patch and > > i'll be happy to investigate. > > > > Any other feedback on that adsdr patch? I have a semi free weekend ahead > > and should be able to fix bugs or rewrite it completely depending on how > > bad it is :) Or maybe clean up the code and get it ready for check in? > > If anyone has time to review the code that would be greately appreciated. > > > > Also, if there are no objections, i could look into those enhancement > > requests that Mark made at the bottom of the e-mail. Should be pretty > > straight forward i assume, but i don't want to do that if someone is > > already looking into it :) > > > > Regards, > > Vladimir. > > Vladimir, > Hi. I don't know what's happening on my end, but downloading LS this > morning and building it I seem to either get no sound at all, or I get > sound but only after a while. > > I've had some updates on this machine, so maybe its a gcc/glibc > issue. I don't know yet. The adsdr6 patch file applies cleanly against > today's CVS. I then edit the code in alsaio.cpp to go to 1,0 instead of > 0,0, then ./configure and make. The code starts, looks normal, sees Jack > if I have it running, but I get no MIDI events into it even though > kaconnect says it's hooked up. > > Sometimes after a while I see a burst of MIDI and a whole bunch of > noise, but mostly nothing. > > I'll see if I can figure this out, but it may be beyond my limited > skills. It appears that when this happens it is taking out either all of > Alsa or my HDSP 9652 driver. After the problem occurs in LS I'm unable > to do anythingwith audio without a reboot. Even stopping and restarting > Alsa isn't working. > > Not a nice start to the day... > > Take care, > Mark > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > |
|
From: Vladimir S. <ha...@so...> - 2004-02-01 07:47:25
Attachments:
outputcard.gz
|
Mark, Here is a patch to add --outputcard option. It is against latest CVS and isolated from any other patches. I'll look into adding a jack option you suggested tomorrow. Do you think we need to change the logic that LS follows when opening audio? Currently, it tries jack first and if that fails it opens alsa. Should we skip jack alltogether if --outputcard option is specified? Regards, Vladimir. Mark Knecht wrote: >On Sun, 2004-01-18 at 17:22, Vladimir Senkov wrote: > > >>Mark, >>Last e-mail :) >> >>Few small things here but mostly to try out a hack to implement >>"re-sustain" effect we talked about earlier. >>For now, just a "proof of concept", it will be coded differently. for >>now i just created a global because there is no easy way to link sustain >>to voices after ProcessNoteOff(). >>Let me know how it feels with different samples. My impression is that >>it sounds fairly accurate with samples that have infinite sustain >>disabled (such as that free Steinway sample i'm using), but perhaps a >>bit too strong with infinite sustain samples such as Church Organ for >>example. >>I'm thinking about making that second sustain stage non-infinite just >>like decay2 even for samples with infinite sustain. Any thoughts on this? >>I'll test it with GS next weekend to see how it does it with different >>samples. >> >>Regards, >>Vladimir. >> >>PS: patch is not incremental. Apply to latest CVS. >> >> > >Vladimir & Christian, > OK, I've installed today's CVS with ADSDR6. It seems to be working >fine so far. It correctly determines if Jack is running. If Jack is not >running it does what it did before. However, I needed to edit >audioio.cpp before and what I needed to edit appears to have moved. >Could I make my first simple enhancement request? Could we have a >command line option to tell it which sound card to use? Earlier I was >changing plughw:0 to plughw:1. Could the number be changed to be a >command line option? (--card "plughw:1") > > If Jack is running it connects to the the Jack server, but it doesn't >connect the audio path automatically. Could I make my second request to >have a command line option to make this connection? (--jack-ch >"playback_1, playback_2" - I.e. don't forget stereo vs. mono...) > > Also, I think it would be helpful to have LS print some sort of >revision info when it starts. I have so many versions now I'd like to be >sure when I install a new version that I'm really using it. ;-) > > OK, with that all behind me it appears that LS is working well with >Jack. No clicks of pops so far. The only negative thing I've noticed so >far is that with a lot of notes playing I seem to be getting a lot of >hiss in the background. As the notes die away the hiss goes away, so it >appears to be part of the sample, but in LS I *think* I'm getting a lot >more hiss now? Could this be part of the ADSDR edit, or could it have >something to do with using Jack? > > I need to go back and find the code that moved so that I can use my >HDSP 9652 without Jack, or wait for you all to add the card choice >enhancement. > > I'll start playing with more gigs and see what I come up with, but my >first impression is very positive. > >Cheers, >Mark > > > >------------------------------------------------------- >The SF.Net email is sponsored by EclipseCon 2004 >Premiere Conference on Open Tools Development and Integration >See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. >http://www.eclipsecon.org/osdn >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > |
|
From: David O. <da...@ol...> - 2004-01-11 22:20:33
|
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 --- |
|
From: Christian S. <chr...@ep...> - 2004-01-12 00:00:19
|
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 |
|
From: Christian S. <chr...@ep...> - 2004-01-12 00:18:20
|
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 |
|
From: Mark K. <mar...@co...> - 2004-01-12 00:51:02
|
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 |
|
From: David O. <da...@ol...> - 2004-01-12 10:49:50
|
On Monday 12 January 2004 01.50, Mark Knecht wrote: > On Sun, 2004-01-11 at 15:55, Christian Schoenebeck wrote: > > > =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...) > > > > 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. Actually, I think the intention is to make it easy to program natural=20 envelopes for looping samples. Nature tends to be exponential rather=20 than linear. :-) And indeed, I *am* having trouble with the linear envelopes in=20 Audiality, even with the off-line synth, which has multi-section EGs.=20 Just look at the cymbals and stuff like that... *hehe* There's a new=20 EG output transformation feature now, but it doesn't seem to do the=20 job well enough. Could have screwed something up there, though; that=20 feature has hardly been tested. > 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. Or "voice stealing", as it's usually called... When allocating a new=20 voice, I just =091) look for free voices =092) look for the softest voice with same or lower priority =093) steal the lowest priority voice (same or lower) =094) fail Now that I think of it, I'm not quite sure what I was thinking there,=20 around steps 2 and 3. Hmm... It should probably look like this: =091) look for free voices =092) look for softer voices with same or lower priority =093) use the softest voice with same or lower priority =094) fail (That is, first try to find a softer voice. If that fails, just use=20 the softest one found.) Anyway, I just brutally kill stolen voices. It appears that quite a=20 few h/w synths do that as well, but that doesn't make it an=20 acceptable solution, IMHO. One should use some "low cost" temporary=20 voice mixer or something, to allow the stolen voice to die without=20 clicking. BTW, priorities is what I use to keep sound effects from killing long=20 notes in in-game music and stuff like that. Simple and handy, and=20 works well as a generic improvement of the voice stealing system. You=20 can't (ab)use it to make polyphonic patches monophonic, though. Some Roland synths use a "voice reserve" system instead, which allows=20 you to allocate a fixed number of voices for each part (ie "MIDI=20 channel", sort of). That has other limitations, but it sort of does=20 the job, unless you're very low on voices and have many parts. All=20 parts without voice reserves just fight for the remaining voices. > 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. Right, but don't forget to actually check whether the voices just have=20 a slow release, or if they're in the sustain state, waiting for=20 note-off. However, even if you do that, there's always the risk of=20 stealing the wrong voice. You'd probably have to do a continuous=20 spectrum analysis of all playing voices to reliably tell which one is=20 the least audible - and even then, you can't tell whether the note=20 you just killed will be the only one still playing a second from now!=20 :-) That reminds me; I once had this idea about "voice unstealing". I'm thinking about implementing it in Audiality, using dummy voices to=20 keep the EGs and stuff alive and running, until there are free=20 physical voices available. The dummy voices would not mix or=20 anything, but just do what they need to keep track of the current=20 pitch, volume, playback position etc, so they can force load a=20 physical voice at any time. Before I do that, though, I should probably benchmark the code and see=20 what kind of CPU time ratio there is between the control stuff and=20 the voice mixers... :-) //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 --- |
|
From: Mark K. <mar...@co...> - 2004-01-12 15:14:16
|
On Mon, 2004-01-12 at 02:49, David Olofson wrote: > > 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. > > Or "voice stealing", as it's usually called... When allocating a new > voice, I just > 1) look for free voices > 2) look for the softest voice with same or lower priority > 3) steal the lowest priority voice (same or lower) > 4) fail > > Now that I think of it, I'm not quite sure what I was thinking there, > around steps 2 and 3. Hmm... It should probably look like this: > > 1) look for free voices > 2) look for softer voices with same or lower priority > 3) use the softest voice with same or lower priority > 4) fail > > (That is, first try to find a softer voice. If that fails, just use > the softest one found.) In my simple mind I was thinking last night (when I wrote this) of the way LS works today with a single gig library and not the way it's going to work in the future with many gig libraries. (I hope!) I would like to request that as a starting point the developers follow the logic of what you are presenting here Dave, but with one small addition. Please consider guaranteeing a specific minimum number of voices to each gig library that is loaded. This would help ensure that a soft violin in the background doesn't have all it's notes stolen by a loud piano using sustain that already has 99% of the notes anyway. > BTW, priorities is what I use to keep sound effects from killing long > notes in in-game music and stuff like that. Simple and handy, and > works well as a generic improvement of the voice stealing system. You > can't (ab)use it to make polyphonic patches monophonic, though. I think priorities could address my request. If the first X number of voices for any gig were high priority, then the piano's 50th note couldn't steal the violin's 1st note no matter how soft it was. > > 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. > > Right, but don't forget to actually check whether the voices just have > a slow release, or if they're in the sustain state, waiting for > note-off. Right. Good point. > That reminds me; I once had this idea about "voice unstealing". > > I'm thinking about implementing it in Audiality, using dummy voices to > keep the EGs and stuff alive and running, until there are free > physical voices available. The dummy voices would not mix or > anything, but just do what they need to keep track of the current > pitch, volume, playback position etc, so they can force load a > physical voice at any time. > > Before I do that, though, I should probably benchmark the code and see > what kind of CPU time ratio there is between the control stuff and > the voice mixers... :-) > I made this point once before, but I don't think anyone responded to it. If I benchmark the number of voices used in GSt and LS to render that jazz piano ogg I've posted then the release samples are FAR more important from a CPU/disk usage point of view than the main key strike notes. Currently, that piano piece uses about 90 voices max in GSt, while the same piece uses only 10-12 voices in LS today. With no release samples you would not expect a piano (without sustain) to every use more than 10 notes, and indeed it doesn't. However, once release samples are included the faster melodic runs can end up with many voices active in the release state with just a few new notes in the key press state. (Active state? Note on state? What term should I use?) I think that doing very much benchmarking before release samples are included is only going to lead to doing it again. In the piano ogg above, what you hear from LS today is only 10-15% of what GSt is doing with the same MIDI file. - Mark |
|
From: David O. <da...@ol...> - 2004-01-12 16:14:00
|
On Monday 12 January 2004 16.14, Mark Knecht wrote: [...] > > BTW, priorities is what I use to keep sound effects from killing > > long notes in in-game music and stuff like that. Simple and > > handy, and works well as a generic improvement of the voice > > stealing system. You can't (ab)use it to make polyphonic patches > > monophonic, though. > > I think priorities could address my request. If the first X number > of voices for any gig were high priority, then the piano's 50th > note couldn't steal the violin's 1st note no matter how soft it > was. That should work - and it has the advantage of not having to figure=20 out some "sensible" number of voices to reserve for each gig, MIDI=20 port, MIDI channel or whatever. [...] > > Before I do that, though, I should probably benchmark the code > > and see what kind of CPU time ratio there is between the control > > stuff and the voice mixers... :-) > > I made this point once before, but I don't think anyone responded > to it. If I benchmark the number of voices used in GSt and LS to > render that jazz piano ogg I've posted then the release samples are > FAR more important from a CPU/disk usage point of view than the > main key strike notes. As expected... Those slow releases and stuff (whether they're just=20 looping + envelopes, or special samples) are the main reason why h/w=20 synths have 64-256 voices these days, I think. > (Active state? Note on state? What term should I > use?) I would suggest a separation of EG/voice states and MIDI terminology.=20 NoteOn, NoteOff and various ControlChange events are just ways of=20 suggesting what the EG should do. Depending on the patch, it may=20 react instantly, react based on what state it's in or ignore events=20 entirely. Nothing says that NoteOff is special. Lots of instruments=20 don't have a corresponding function, or releasing a keyboard key to=20 stop a note just doesn't feel right; it may make more sense to use=20 NoteOn only and use low velocities for muting notes. Whatever. Put in an abstraction layer between MIDI and the voice state machine,=20 and try to come up with terminology that doesn't seem to suggest that=20 some MIDI events directly affect the state of the EG. (I have some=20 cleaning up to do in that area in Audiality too, I think.) > I think that doing very much benchmarking before release samples > are included is only going to lead to doing it again. In the piano > ogg above, what you hear from LS today is only 10-15% of what GSt > is doing with the same MIDI file. Those 85-90% doesn't add *that* much to the experience, though! ;-) //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 --- |
|
From: Mark K. <mar...@co...> - 2004-01-12 16:36:58
|
On Mon, 2004-01-12 at 08:13, David Olofson wrote: > > I think priorities could address my request. If the first X number > > of voices for any gig were high priority, then the piano's 50th > > note couldn't steal the violin's 1st note no matter how soft it > > was. > > That should work - and it has the advantage of not having to figure > out some "sensible" number of voices to reserve for each gig, MIDI > port, MIDI channel or whatever. And gives the user some control. If this could be a per 'port' setting in the LS GUI that would be pretty cool. (A 'port' in GSt is the place a Gig file sits and responds to specific MIDI channel.) If I could say my piano will always get 10 voices, my violin will always get 3, etc., then I can tune that song by song as necessary. > > > I think that doing very much benchmarking before release samples > > are included is only going to lead to doing it again. In the piano > > ogg above, what you hear from LS today is only 10-15% of what GSt > > is doing with the same MIDI file. > > Those 85-90% doesn't add *that* much to the experience, though! ;-) > Well, around library developers I think this statement verges on the religious, so I won't respond about their value beyond this sentence. ;-) That said, I think my point that by adding the release sample support sooner vs. later in LS would allow us to improve the disk handling of samples, better look at the overhead of the envelope generators (and all the other stuff like LFO's, looping, etc.) and thus better benchmark how well we're doing vs. the GSt solution. I can run GSt and LS on the same machine with the same sample drives and same sound card. It's about as apples to apples as we're going to get. I do understand it will happen when it happens though. That's the way of Linux development! |
|
From: David O. <da...@ol...> - 2004-01-12 17:31:26
|
On Monday 12 January 2004 17.36, Mark Knecht wrote: > On Mon, 2004-01-12 at 08:13, David Olofson wrote: > > > I think priorities could address my request. If the first X > > > number of voices for any gig were high priority, then the > > > piano's 50th note couldn't steal the violin's 1st note no > > > matter how soft it was. > > > > That should work - and it has the advantage of not having to > > figure out some "sensible" number of voices to reserve for each > > gig, MIDI port, MIDI channel or whatever. > > And gives the user some control. If this could be a per 'port' > setting in the LS GUI that would be pretty cool. (A 'port' in GSt > is the place a Gig file sits and responds to specific MIDI > channel.) If I could say my piano will always get 10 voices, my > violin will always get 3, etc., then I can tune that song by song > as necessary. Yeah. That's what the Roland JV-1080 and later synths do, BTW. Seems=20 to do the job, but most of the time I managed to get away without=20 using it. (64 voices and not too many sounds with extremely slow=20 releases. And some other h/w at times...) [...] > > Those 85-90% doesn't add *that* much to the experience, though! > > ;-) > > Well, around library developers I think this statement verges on > the religious, so I won't respond about their value beyond this > sentence. ;-) *hehe* Well, let's hope they don't take that more seriously than it=20 was intended! :-) > That said, I think my point that by adding the release sample > support sooner vs. later in LS would allow us to improve the disk > handling of samples, better look at the overhead of the envelope > generators (and all the other stuff like LFO's, looping, etc.) and > thus better benchmark how well we're doing vs. the GSt solution. I > can run GSt and LS on the same machine with the same sample drives > and same sound card. It's about as apples to apples as we're going > to get. Yeah. The disk streaming and voice mixing (mostly a memory bandwidth=20 thing with simple interpolators, I think) is probably the most=20 critical part WRT performance. Next would be filters and stuff, but=20 control structure and most "little features" probably don't have that=20 a massive impact on performance. //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 --- |
|
From: <be...@ga...> - 2004-01-27 05:13:05
|
Scrive David Olofson <da...@ol...>: > > > I think that doing very much benchmarking before release samples > > are included is only going to lead to doing it again. In the piano > > ogg above, what you hear from LS today is only 10-15% of what GSt > > is doing with the same MIDI file. > > Those 85-90% doesn't add *that* much to the experience, though! ;-) Keep in mind LS counts stereo voices while GS counts mono voices. Thus when doing comparisons multiply LS voices by two first (or divide GS voices by two). I think when release samples and other stuff will be added the voice difference will not be that big (except if the two samplers do use different sustain algorithm (eg sustaining any voice added or only the last 1-2 voices per midi key). cheers, Benno http://www.linuxsampler.org ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: <be...@ga...> - 2004-01-27 14:32:39
|
Mark keep in mind that GSt shows you mono voice count while LS shows you stereo voice count. So be sure to multiply LS voices by two when comparing them with GSt voices. So basically 12 LS voices means 24 GSt voices. Of course with release samples voice count will go up in LS but as said the LS streaming engine is powerful enough to deliver the performance which is comparable to GSt. BTW: just back from NAMM, grat show, had interesting meetings regarding LS will tell you guys more here on the list tomorrow. I'm still tired of a total of 24h trip + 9h of time lag so I need to get some sleep. cheers, Benno http://www.linuxsampler.org Scrive Mark Knecht <mar...@co...>: > > Currently, that piano piece uses about 90 voices max in GSt, while the > same piece uses only 10-12 voices in LS today. With no release samples > you would not expect a piano (without sustain) to every use more than 10 > notes, and indeed it doesn't. However, once release samples are included > the faster melodic runs can end up with many voices active in the > release state with just a few new notes in the key press state. (Active > state? Note on state? What term should I use?) > > I think that doing very much benchmarking before release samples are > included is only going to lead to doing it again. In the piano ogg > above, what you hear from LS today is only 10-15% of what GSt is doing > with the same MIDI file. > > - Mark ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: David O. <da...@ol...> - 2004-01-12 10:20:06
|
On Monday 12 January 2004 00.55, Christian Schoenebeck wrote: > Es geschah am Sonntag, 11. Januar 2004 23:20 als David Olofson=20 schrieb: > > On Sunday 11 January 2004 18.10, Christian Schoenebeck wrote: > > [..] > > > > > PADSDR > > > > [..] > > > > ???-Attack-Decay-Sustain-Delay-Release? > > > > Some questions: > > =09* What's the first state? > > Sorry, that's just the PreAttack value, thus the value from which > the Attack stage will start. I see. Turns out I have that in Audiality as well, though I didn't=20 remember. :-) (I usually start at 0 with short looped waveforms, to=20 avoid clicks. The timing is sample accurate, so you can still make=20 very fast attacks.) There are 10 parameters total, actually; not just DAHDSR. (Those are=20 just the *states* anyway, right?) Here's the doc from enums.h: /* * DAHDSR envelope generator parameters: * * Level * ^ * | __L1__ * | /| |\ * | / | | \ * |__L0__/ | | \__L2__ * | | | | | |\ * | D | A | H | D | S |R\ * |_____|___|____|___|____|__\____\ * | | | | | | | / Time * DELAY T1 HOLD T2 T3 T4 * * State by state description: * * D: Set to L0, and hold for DELAY seconds. * A: Ramp to L1 over T1 seconds. * H: Hold at L1 for HOLD seconds. * D: Ramp to L2 over T2 seconds. * S: if T3 < 0 * Hold at L2 until CE_STOP is received. * else * Hold at L2 for T3 seconds. * R: Ramp to 0 over T3 seconds. * * If T3 is set to a negative value, sustain lasts until * a CE_STOP event is received. If T3 is 0 of higher, * sustain lasts for T3 seconds. * * The EG will *always* load L0, but from then on, if a * phase has a zero duration, that phase is skipped. * Note that skipping any of the A, D and R phases will * produce clicks, unless the adjacent levels are * identical. * * In some cases, it's desirable that the EG immediately * skips to the release phase when a CE_STOP event is * received, whereas in other cases, this would result * in problems with very short notes. Therefore, there is * a boolean control 'ENV_SKIP' that make it possible to * specify which behavior is desired. * '1' will make the EG skip to release upon receiving * CE_STOP. '0' will result in the EG taking no action * on CE_STOP until the sustain phase is reached the * normal way. * 'ENV_SKIP' has no effect if "timed sustain" is used; * T3 must be < 0, or CE_STOP is entirely ignored. * */ That is, it's pretty much flat section, ramped section, flat section,=20 =2E.. etc, and a switch for "interactive sustain". [...] > > =09* Why no Hold between Attack and Decay? > > =09 (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). That's yet another variant, though. My "hold" is E-mu (IIRC)=20 terminology, and is just the duration of the flat section between the=20 attack and the decay. The Giga variant sounds handy as well, though. How about some system=20 that allows all sorts of events to trigger and/or "permit" EG state=20 changes? For example, one would handle the sustain pedal in a similar=20 way to how I handle note-off in Audiality. Any control could be=20 linked to any envelope section. > 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. Yeah. That's why I ended up with the DAHDSR variant I'm using. I just=20 realized eventually, that the code would have been smaller, cleaner=20 and more flexible if I had went for the generic version right away.=20 There's a pretty long switch() in there now, and the cases are=20 confusingly similar. :-) > > =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...) > > 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? Ah. Another nice feature. :-) [...roadmap...] Makes a lot of sense. Don't get sidetracked by my suggestions. :-) I'm=20 just brainstorming, basically, thinking about stuff that is or might=20 be useful in LS as well as Audiality. BTW, I released Audiality 0.1.1 the other day, in case you haven't=20 noticed. The current version of the EG is in there (a_patch.c), in=20 case the code could be of use in any way. //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 --- |
|
From: Christian S. <chr...@ep...> - 2004-01-18 19:53:29
|
Es geschah am Freitag, 16. Januar 2004 04:52 als Vladimir Senkov schrieb: > I figured i better send a patch so it will be easier for folks to try it > out: > > --- a/src/audiothread.cpp Sun Jan 11 11:43:54 2004 > +++ b/src/audiothread.cpp Thu Jan 15 22:44:50 2004 > @@ -319,11 +319,11 @@ > (*pVoicePtr)->Release(); > pVoicePtr = pVoicePtrNext; > } > + > SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode); > + pMIDIKeyInfo[*key].pSustainPoolNode = NULL; > + pMIDIKeyInfo[*key].Sustained = false; > + pMIDIKeyInfo[*key].hSustainPtr = NULL; > } > - > SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode); > - pMIDIKeyInfo[*key].pSustainPoolNode = NULL; > - pMIDIKeyInfo[*key].Sustained = false; > - pMIDIKeyInfo[*key].hSustainPtr = NULL; > } > //SustainedKeyPool->empty(); > } > > This should take care of that little problem with voices getting stuck . . > . Christian, does this make sense? Very good Vladimir! That was the problem; is now fixed in today's CVS version. Cu Christian |
|
From: Christian S. <chr...@ep...> - 2004-01-18 20:48:30
|
Es geschah am Sonntag, 18. Januar 2004 21:09 als Vladimir Senkov schrieb: > Cool. > I've pulled down the latest LS from cvs but it looks the same as before > though. is there any replication involved? Now it is. Just a bit patience! ;) |
Thanks for helping keep SourceForge clean.
X