Menu
▾
▴
linuxsampler-devel
|
From: Rui N. C. <rn...@rn...> - 2004-07-02 16:07:05
|
Christian, >> Please note that the C++ source code wasn't touched in any way. On >> attachment you may find a complete diff-patch of the proposed changes. > > Looks fine, except: > >>>diff -duPr libgig-0.7.0/libgig.spec.in libgig-0.7.1/libgig.spec.in > >>+Copyright: LGPL > > That's GPL, not LGPL at the moment. > Of course. Sorry :) > >>+URL: http://www.linuxsampler.org/ > > That should be http://stud.fh-heilbronn.de/~cschoene/projects/libgig/ for > the moment, I will move the site to http://www.linuxsampler.org/ though > when I have time (in a couple of weeks). > Right. >> diff -duPr libgig-0.7.0/src/Makefile.am libgig-0.7.1/src/Makefile.am >> --- libgig-0.7.0/src/Makefile.am 2004-05-03 15:16:58.000000000 +0100 >> +++ libgig-0.7.1/src/Makefile.am 2004-07-01 10:19:08.000000000 +0100 >> @@ -1,11 +1,11 @@ >> -# set the include path found by configure >> -INCLUDES= $(all_includes) >> - >> # to prevent compile errors on some systems >> AM_CXXFLAGS = -pedantic >> >> -pkglib_LTLIBRARIES = libgig.la >> -libgig_la_SOURCES = RIFF.cpp RIFF.h DLS.cpp DLS.h gig.cpp gig.h >> +libgigincludedir = $(includedir) >> +libgiginclude_HEADERS = RIFF.h DLS.h gig.h >> + >> +lib_LTLIBRARIES = libgig.la > > Is there a reason to replace pkglib_LTLIBRARIES by lib_LTLIBRARIES? > No special reason. IIRC I was having some trouble with the libtoolization which seemed to be solved by that change. Something regarding the target shared libraries not having the .so suffix or else. I've never and probably never will grok the misteries of the autotools karma :) BTW, do you know the difference between pkglib_ and lib_ prefixes? The later seems to be more standard :) Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-07-02 17:53:35
|
Es geschah am Freitag, 2. Juli 2004 18:04 als Rui Nuno Capela schrieb:
> > Is there a reason to replace pkglib_LTLIBRARIES by lib_LTLIBRARIES?
>
> No special reason. IIRC I was having some trouble with the libtoolization
> which seemed to be solved by that change. Something regarding the target
> shared libraries not having the .so suffix or else. I've never and
> probably never will grok the misteries of the autotools karma :)
>
> BTW, do you know the difference between pkglib_ and lib_ prefixes? The
> later seems to be more standard :)
I wasn't sure either, but AFAIK the only difference is the target directory=
=2E=20
=46rom the libtool doc ("9.3.2 Building Libtool Libraries"):
> Automake predefines the variable `pkglibdir', so you can use=20
> pkglib_LTLIBRARIES to install libraries in $(libdir)/@PACKAGE@/. =20
That was the only difference I found.
So, it's ok, go ahead and commit it.
CU
Christian
|
|
From: Rui N. C. <rn...@rn...> - 2004-07-02 19:01:08
|
Christian,
>>
>> BTW, do you know the difference between pkglib_ and lib_ prefixes? The
>> later seems to be more standard :)
>
> I wasn't sure either, but AFAIK the only difference is the target
> directory.
>>From the libtool doc ("9.3.2 Building Libtool Libraries"):
>
>> Automake predefines the variable `pkglibdir', so you can use
>> pkglib_LTLIBRARIES to install libraries in $(libdir)/@PACKAGE@/.
>
> That was the only difference I found.
>
That's it. I remember now that I disliked to install the libraries under
"${prefix}/lib/libgig" (as the pkglib_ prefix seems to imply) and
preferred the "${prefix}/lib" instead. One less line under
"/etd/ld.so.conf" is one less line under my worries.
Feeling even better now.
> So, it's ok, go ahead and commit it.
>
I'll do it after changing the License and URL on the specfile as you asked.
Is it also OK to remove from CVS all those auto-generated files? I mean
the ones generated after a 'make -f Makefile.cvs' ? I don't see the point
having it on the repository, do you?
--
rncbc aka Rui Nuno Capela
rn...@rn...
|
|
From: Christian S. <chr...@ep...> - 2004-07-02 19:40:38
|
Es geschah am Freitag, 2. Juli 2004 20:58 als Rui Nuno Capela schrieb: > > So, it's ok, go ahead and commit it. > > I'll do it after changing the License and URL on the specfile as you asked. Good. > Is it also OK to remove from CVS all those auto-generated files? I mean > the ones generated after a 'make -f Makefile.cvs' ? I don't see the point > having it on the repository, do you? Yes I do. The advantage is you can compile the library even without having to install the auto tools. That's why they are there. It's like the same with the parser in LS. You can regenerate it if you have lex & yacc installed by doing 'make parser', or just stick with our pregenerated parser source files. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-07-02 21:39:39
|
Christian, > >> Is it also OK to remove from CVS all those auto-generated files? I mean >> the ones generated after a 'make -f Makefile.cvs' ? I don't see the >> point having it on the repository, do you? > > Yes I do. The advantage is you can compile the library even without > having to install the auto tools. That's why they are there. > > It's like the same with the parser in LS. You can regenerate it if you > have lex & yacc installed by doing 'make parser', or just stick with our > pregenerated parser source files. > Oops, about too late. Already committed. Damn, it was just minutes ago. To save the day, I can always do the autocrap-bootstrap myself and check in the regenerated files, if it pleases you. Must I? Sorry for the inconvenience. I didn't mean no harm. OTOH, I've already packaged all my stuff, which is available on the usual place (http://www.rncbc.org/ls). You might build your (official) tarball now :) Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-07-02 22:44:20
|
Es geschah am Freitag, 2. Juli 2004 23:36 als Rui Nuno Capela schrieb: > >> Is it also OK to remove from CVS all those auto-generated files? I mean > >> the ones generated after a 'make -f Makefile.cvs' ? I don't see the > >> point having it on the repository, do you? > > > > Yes I do. The advantage is you can compile the library even without > > having to install the auto tools. That's why they are there. > > > > It's like the same with the parser in LS. You can regenerate it if you > > have lex & yacc installed by doing 'make parser', or just stick with our > > pregenerated parser source files. > > Oops, about too late. Already committed. Damn, it was just minutes ago. > > To save the day, I can always do the autocrap-bootstrap myself and check > in the regenerated files, if it pleases you. Must I? Np, forget it. I forgot the libtool aspect. You need to have libtool installed to create the lib and libtool has a dependency to parts of autotools. so ... > OTOH, I've already packaged all my stuff, which is available on the usual > place (http://www.rncbc.org/ls). You might build your (official) tarball > now :) Yeah, maybe tomorrow. Btw, you could also commit the Borland/Win stuff. Maybe you create a win32 directory or something for the fake headers. Once gigextract's dependency to libaudiofile is replaced by libsndfile, then even gigextract will be conveniently compilable on Windows. CU Christian |
|
From: Christian S. <chr...@ep...> - 2004-07-02 22:58:03
|
Es geschah am Freitag, 2. Juli 2004 23:36 als Rui Nuno Capela schrieb: > >> Is it also OK to remove from CVS all those auto-generated files? I mean > >> the ones generated after a 'make -f Makefile.cvs' ? I don't see the > >> point having it on the repository, do you? > > > > Yes I do. The advantage is you can compile the library even without > > having to install the auto tools. That's why they are there. > > > > It's like the same with the parser in LS. You can regenerate it if you > > have lex & yacc installed by doing 'make parser', or just stick with our > > pregenerated parser source files. > > Oops, about too late. Already committed. Damn, it was just minutes ago. > > To save the day, I can always do the autocrap-bootstrap myself and check > in the regenerated files, if it pleases you. Must I? Np, forget it. I forgot the libtool aspect. You need to have libtool installed to create the lib and libtool has a dependency to parts of autotools. so ... > OTOH, I've already packaged all my stuff, which is available on the usual > place (http://www.rncbc.org/ls). You might build your (official) tarball > now :) Yeah, maybe tomorrow. Btw, you could also commit the Borland/Win stuff. Maybe you create a win32 directory or something for the fake headers. Once gigextract's dependency to libaudiofile is replaced by libsndfile, then even gigextract will conveniently be compilable on Windows. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2004-07-03 00:01:13
|
Christian, >> > > Btw, you could also commit the Borland/Win stuff. Maybe you create a > win32 directory or something for the fake headers. Once gigextract's > dependency to libaudiofile is replaced by libsndfile, then even > gigextract will conveniently be compilable on Windows. > I'll do that when I get back to my workplace, where I do the windoze dance :) and look closer to a bunch of warnings the compiler spitted out. As I said it's not a priority. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Christian S. <chr...@ep...> - 2004-07-07 12:17:24
|
Hi! I felt forced to add support for generating Debian packages as well. ;) I commited it couple of minutes ago. Rui, could you please also put a line into README how to generate the RPMs? I just left a TODO there, hoping you will do it. Right after that I will roll the tarball and generate the .deb files and upload them together with your RPMs. CU Christian P.S. in configure.in you can now set the version of the generated shared library (.so file). I left it with 0:0:0 for the moment due to the version number constraints of libtool which would not allow a version of 0:0:7 Es geschah am Samstag, 3. Juli 2004 01:57 als Rui Nuno Capela schrieb: > Christian, > > > Btw, you could also commit the Borland/Win stuff. Maybe you create a > > win32 directory or something for the fake headers. Once gigextract's > > dependency to libaudiofile is replaced by libsndfile, then even > > gigextract will conveniently be compilable on Windows. > > I'll do that when I get back to my workplace, where I do the windoze dance > > :) and look closer to a bunch of warnings the compiler spitted out. > > As I said it's not a priority. > > Cheers. |
|
From: Rui N. C. <rn...@rn...> - 2004-07-07 13:03:51
|
Hi Christian, > > I felt forced to add support for generating Debian packages as well. ;) > I commited it couple of minutes ago. > > Rui, could you please also put a line into README how to generate the > RPMs? I just left a TODO there, hoping you will do it. Right after that > I will roll the tarball and generate the .deb files and upload them > together with your RPMs. > To generate the RPMs you have to be on a RPM based system/distro, or at least have the rpmbuild tool properly configured. I take my knowledge because all my boxes have RPM based distros (suse, mdk and fedora). But things may differ The steps are simple: 1) Get .spec file generated by ./configure. Edit it as appropriate. Then, as root: 2) Copy the source tarball to "/usr/src/<rpmdir>/SOURCES" directory. 3) Build the rpm(s) by invoking 'rpmbuild -bb <specfile>' from the command line. On success, the resulting rpm(s) can usually be found under the proper "/usr/src/<rpmdir>/RPMS/<arch>" directory. The recently built package(s) aren't installed by default. The names for the sub-directories <rpmdir> and <arch> depends on the distro or rpm installation. For example, on SUSE we have <rpmdir>="packages", on Mandrake <rpmdir> is "RPM" and for redhat/fedora <rpmdir> always equals "redhat". As you see, I don't feel very sure about writing /so/ specific instructions, as YMMV. Feel free to drop yourself a line on the README file. At the moment I don't have access to make it right, maybe tonight. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Rui N. C. <rn...@rn...> - 2004-09-28 16:24:39
|
Hi, Long time, eh? qsampler 0.0.3.2: * Sampler reset command action added to menu and toolbar. * MIDI channel selection is now a dropdown list, allowing the explicit selection for "All" channels input per sampler channel (omni). * Channel strip display glass effect has changed background color to black (was green). * Minor configure fixes. liblscp 0.2.3: * Fixed lscp_set_channel_midi_channel() where MIDI channels should be given in the range 1-16, and omni mode with new LSCP_MIDI_CHANNEL_ALL symbol (0). * Rearrangement on main command requester executive. Bye. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Mark K. <mar...@co...> - 2004-01-11 17:56:57
|
Christian, Going to get it now. I do not see in the LS front page description of this release that you added the two fixes you and I worked on last weekend. Did those get included? Thanks, Mark On Sun, 2004-01-11 at 09:10, Christian Schoenebeck wrote: > Changes: > > - There was still this annoying problem that some .gig instruments were > detuned. I hope I have fixed this now. If you have still a .gig that > sounds detuned, please let me know! > > - As promised I finished an initial version of the amplitude envelope > generator (EG1), so far only a simple ASR one. Extending it to a PADSDR > one (as used in Gigasampler) is quite easy. If anybody likes to do this > task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir > perhaps? > The EG has a minimum release time, in case the release time given by the > gig file is 0s for example. Without this min. release time we would again > have the click problem in case of zero release times when the voice will > be released before it's sample end. This min. release time is defined in > line 32 of src/eg_vca.h and there's another #define which sets the bottom > value limit of the Exp curve, thus also defines the end of the EG curve in > general. These two #define values still have to be adjusted to good values > > CU > Christian > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Mark K. <mar...@co...> - 2004-01-11 18:00:06
|
SORRY!!! Stupid me! You show that in the previous release! My apologies!!! - Mark On Sun, 2004-01-11 at 09:56, Mark Knecht wrote: > Christian, > Going to get it now. I do not see in the LS front page description of > this release that you added the two fixes you and I worked on last > weekend. Did those get included? > > Thanks, > Mark > > On Sun, 2004-01-11 at 09:10, Christian Schoenebeck wrote: > > Changes: > > > > - There was still this annoying problem that some .gig instruments were > > detuned. I hope I have fixed this now. If you have still a .gig that > > sounds detuned, please let me know! > > > > - As promised I finished an initial version of the amplitude envelope > > generator (EG1), so far only a simple ASR one. Extending it to a PADSDR > > one (as used in Gigasampler) is quite easy. If anybody likes to do this > > task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir > > perhaps? > > The EG has a minimum release time, in case the release time given by the > > gig file is 0s for example. Without this min. release time we would again > > have the click problem in case of zero release times when the voice will > > be released before it's sample end. This min. release time is defined in > > line 32 of src/eg_vca.h and there's another #define which sets the bottom > > value limit of the Exp curve, thus also defines the end of the EG curve in > > general. These two #define values still have to be adjusted to good values > > > > CU > > Christian > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Perforce Software. > > Perforce is the Fast Software Configuration Management System offering > > advanced branching capabilities and atomic changes on 50+ platforms. > > Free Eval! http://www.perforce.com/perforce/loadprog.html > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Mark K. <mar...@co...> - 2004-01-11 18:21:19
|
On Sun, 2004-01-11 at 09:10, Christian Schoenebeck wrote: > Changes: > > - There was still this annoying problem that some .gig instruments were > detuned. I hope I have fixed this now. If you have still a .gig that > sounds detuned, please let me know! > > - As promised I finished an initial version of the amplitude envelope > generator (EG1), so far only a simple ASR one. Extending it to a PADSDR > one (as used in Gigasampler) is quite easy. If anybody likes to do this > task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir > perhaps? > The EG has a minimum release time, in case the release time given by the > gig file is 0s for example. Without this min. release time we would again > have the click problem in case of zero release times when the voice will > be released before it's sample end. This min. release time is defined in > line 32 of src/eg_vca.h and there's another #define which sets the bottom > value limit of the Exp curve, thus also defines the end of the EG curve in > general. These two #define values still have to be adjusted to good values > > CU > Christian Christian, Wow!! That's a huge improvement! I've built the new version. It sounds much better. I am getting a few clicks with a fragment size of 128. They do not sound like they are coming at release times, so I'll fire up Pro Tools and do some recording of this version and study what's up with that. It could just be my system. Anyway, great work! Much much better! Oops - spoke a bit too soon. OK, when I first tried using LS I had the fragment size set at 128. I then Ctrl-C'ed out and tried it with 512. I no longer get any audio. I see no MIDI events coming in, which would explain no audio. kaconnect does show my keyboard is hooked up to LS. Strange. I've not seen this problem before. FYI - This is Alsa-1.0.1 I've killed it and gone back to 128, but still not working. Here's my command line. linuxsampler --numfragments 2 --fragmentsize 128 --inputclient 80:1 --instrument 0 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig Cheers, Mark |
|
From: Mark K. <mar...@co...> - 2004-01-11 19:28:55
|
On Sun, 2004-01-11 at 10:20, Mark Knecht wrote: > Oops - spoke a bit too soon. OK, when I first tried using LS I had > the fragment size set at 128. I then Ctrl-C'ed out and tried it with > 512. I no longer get any audio. I see no MIDI events coming in, which > would explain no audio. kaconnect does show my keyboard is hooked up to > LS. Strange. I've not seen this problem before. > > FYI - This is Alsa-1.0.1 > > I've killed it and gone back to 128, but still not working. Here's my > command line. > > linuxsampler --numfragments 2 --fragmentsize 128 --inputclient 80:1 > --instrument 0 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ > Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig > OK, very strange. After doing that Ctrl-C out of LS no audio that I tried would work anymore. (xmms, alsaplayer) They all seemed to be blocked or something. I stopped and restarted Alsa but they didn't work. I rebooted and they were still not working. I had to completely power down to get audio back again. Now I'm going in and out of LS just fine. I'm not getting the clicks when I start LS with a 512 fragment size. I'll post my jazz MIDI test file later today and hold judgment on this audio crash until I get convinced it was a one time event. Cheers, Mark |
|
From: Vladimir S. <ha...@so...> - 2004-01-11 22:04:04
|
Christian, Awesome!!! I can't hear any noises at all with that free Steinway sample and default settings. But . . . I think a bug got introduced in the process. Occasionally, some notes will not release completely. They'll get stuck in a state where i can still hear them but their volume is lower than usual. If i play the same note again it goes away. Kinda feels like a stuck key :) But it's not, because when i play the same thing with old ls (pre cvs update) i don't get into that state. After a while i found a way to reproduce: (other ways may exist also) 1) play and hold note. (voices: 1) 2) apply and hold sustain. 3) release the note (keeps playing on sustain) 4) play and hold the same note again (voices: 2) 4) release sustain 5) apply sustain (hold) 6) release the note 7) release sustain. (voices: 2!) Voices will still be allocated and playing at this point! I'd love to implement PADSDR but i hope it's not very urgent as i need to do a bit of reading first. Regards, Vladimir. Christian Schoenebeck wrote: >Changes: > > - There was still this annoying problem that some .gig instruments were > detuned. I hope I have fixed this now. If you have still a .gig that > sounds detuned, please let me know! > > - As promised I finished an initial version of the amplitude envelope > generator (EG1), so far only a simple ASR one. Extending it to a PADSDR > one (as used in Gigasampler) is quite easy. If anybody likes to do this > task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir > perhaps? > The EG has a minimum release time, in case the release time given by the > gig file is 0s for example. Without this min. release time we would again > have the click problem in case of zero release times when the voice will > be released before it's sample end. This min. release time is defined in > line 32 of src/eg_vca.h and there's another #define which sets the bottom > value limit of the Exp curve, thus also defines the end of the EG curve in > general. These two #define values still have to be adjusted to good values > >CU >Christian > > > >------------------------------------------------------- >This SF.net email is sponsored by: Perforce Software. >Perforce is the Fast Software Configuration Management System offering >advanced branching capabilities and atomic changes on 50+ platforms. >Free Eval! http://www.perforce.com/perforce/loadprog.html >_______________________________________________ >Linuxsampler-devel mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > |
|
From: Mark K. <mar...@co...> - 2004-01-11 22:56:04
|
Hi, I'm hearing the same note-on problems that Vladimir is hearing also. I've posted the jazz bounce done on my end on Pro Tools with the new version of LS at: http://marksmusic.myvnc.com/files/LS_Bounce-2004-01-11.ogg If you listen closely you'll hear a few places where this note-on problem happens. Additionally, I found that usually when I'd finished the MIDI sequence even LS itself knew it had notes on. All notes had quite playing, but the note count had not returned to 100 and LS said it still had 1 stream active. None the less, this is a huge step up in terms of quality. The previous versions (GSt and LS) are here: http://marksmusic.myvnc.com/files/GSt_Bounce-2003-12-21.ogg http://marksmusic.myvnc.com/files/LS_Bounce-2003-12-21.ogg Comparisons are not totally fair as the earlier 2 I had put a bit of reverb on them. This was a mistake for listening for problems, so I think that I will not do that in this forum again. FYI - This server is normally up between 5AM and 10PM California time, so listen during those times. Great work!! Cheers, Mark On Sun, 2004-01-11 at 14:02, Vladimir Senkov wrote: > Christian, > > Awesome!!! > I can't hear any noises at all with that free Steinway sample and > default settings. > > But . . . I think a bug got introduced in the process. > Occasionally, some notes will not release completely. They'll get stuck > in a state where i can still hear them but their volume is lower than usual. > If i play the same note again it goes away. > Kinda feels like a stuck key :) But it's not, because when i play the > same thing with old ls (pre cvs update) i don't get into that state. > > After a while i found a way to reproduce: (other ways may exist also) > 1) play and hold note. (voices: 1) > 2) apply and hold sustain. > 3) release the note (keeps playing on sustain) > 4) play and hold the same note again (voices: 2) > 4) release sustain > 5) apply sustain (hold) > 6) release the note > 7) release sustain. (voices: 2!) > Voices will still be allocated and playing at this point! > > I'd love to implement PADSDR but i hope it's not very urgent as i need > to do a bit of reading first. > > Regards, > Vladimir. > > Christian Schoenebeck wrote: > > >Changes: > > > > - There was still this annoying problem that some .gig instruments were > > detuned. I hope I have fixed this now. If you have still a .gig that > > sounds detuned, please let me know! > > > > - As promised I finished an initial version of the amplitude envelope > > generator (EG1), so far only a simple ASR one. Extending it to a PADSDR > > one (as used in Gigasampler) is quite easy. If anybody likes to do this > > task, you just have to improve the EG_VCA class (src/eg_vca.cpp). Vladimir > > perhaps? > > The EG has a minimum release time, in case the release time given by the > > gig file is 0s for example. Without this min. release time we would again > > have the click problem in case of zero release times when the voice will > > be released before it's sample end. This min. release time is defined in > > line 32 of src/eg_vca.h and there's another #define which sets the bottom > > value limit of the Exp curve, thus also defines the end of the EG curve in > > general. These two #define values still have to be adjusted to good values > > > >CU > >Christian > > > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: Perforce Software. > >Perforce is the Fast Software Configuration Management System offering > >advanced branching capabilities and atomic changes on 50+ platforms. > >Free Eval! http://www.perforce.com/perforce/loadprog.html > >_______________________________________________ > >Linuxsampler-devel mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Mark K. <mar...@co...> - 2004-01-11 23:04:47
|
On Sun, 2004-01-11 at 14:02, Vladimir Senkov wrote: > But . . . I think a bug got introduced in the process. > Occasionally, some notes will not release completely. They'll get stuck > in a state where i can still hear them but their volume is lower than usual. > If i play the same note again it goes away. > Kinda feels like a stuck key :) But it's not, because when i play the > same thing with old ls (pre cvs update) i don't get into that state. Vladimir - what version of Alsa are you using? I just upgraded to 1.0.1 and am having this problem. I did not notice it with 1.0.0-rc2 Mark |
|
From: Vladimir S. <ha...@so...> - 2004-01-12 06:56:08
|
Christian,
I've looked a bit more into this problem.
I think the root cause is in AudioThread::ProcessControlChange()
In particular, hSustainPtr can be set for a key that is still pressed.
In then becomes impossible for ProcessNoteOff() to do the right thing . . .
I tried to put these lines in AudioThread::ProcessControlChange():
SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
pMIDIKeyInfo[*key].Sustained = false;
pMIDIKeyInfo[*key].hSustainPtr = NULL;
into the if statement just above:
if (!pMIDIKeyInfo[*key].KeyPressed) { // release the voices on the key,
if the key is not pressed anymore
so that it will not be done for keys that are still pressed.
I gave it a very quick test and it looks like it's working correctly.
Regards,
Vladimir.
PS: above is written at 2am in the morning under pressure to shut PC
down immediately therefore it can't be trusted :)
Vladimir Senkov wrote:
> Christian,
>
> Awesome!!!
> I can't hear any noises at all with that free Steinway sample and
> default settings.
>
> But . . . I think a bug got introduced in the process.
> Occasionally, some notes will not release completely. They'll get
> stuck in a state where i can still hear them but their volume is lower
> than usual.
> If i play the same note again it goes away.
> Kinda feels like a stuck key :) But it's not, because when i play the
> same thing with old ls (pre cvs update) i don't get into that state.
>
> After a while i found a way to reproduce: (other ways may exist also)
> 1) play and hold note. (voices: 1)
> 2) apply and hold sustain.
> 3) release the note (keeps playing on sustain)
> 4) play and hold the same note again (voices: 2)
> 4) release sustain
> 5) apply sustain (hold)
> 6) release the note
> 7) release sustain. (voices: 2!)
> Voices will still be allocated and playing at this point!
>
> I'd love to implement PADSDR but i hope it's not very urgent as i need
> to do a bit of reading first.
>
> Regards,
> Vladimir.
>
> Christian Schoenebeck wrote:
>
>> Changes:
>>
>> - There was still this annoying problem that some .gig
>> instruments were
>> detuned. I hope I have fixed this now. If you have still a
>> .gig that
>> sounds detuned, please let me know!
>>
>> - As promised I finished an initial version of the amplitude
>> envelope
>> generator (EG1), so far only a simple ASR one. Extending it to
>> a PADSDR
>> one (as used in Gigasampler) is quite easy. If anybody likes
>> to do this
>> task, you just have to improve the EG_VCA class
>> (src/eg_vca.cpp). Vladimir
>> perhaps?
>> The EG has a minimum release time, in case the release time
>> given by the
>> gig file is 0s for example. Without this min. release time we
>> would again
>> have the click problem in case of zero release times when the
>> voice will
>> be released before it's sample end. This min. release time is
>> defined in
>> line 32 of src/eg_vca.h and there's another #define which sets
>> the bottom
>> value limit of the Exp curve, thus also defines the end of the
>> EG curve in
>> general. These two #define values still have to be adjusted to
>> good values
>>
>> CU
>> Christian
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Perforce Software.
>> Perforce is the Fast Software Configuration Management System offering
>> advanced branching capabilities and atomic changes on 50+ platforms.
>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
|
|
From: Vladimir S. <ha...@so...> - 2004-01-16 03:53:51
|
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?
Regards,
Vladimir.
Vladimir Senkov wrote:
> Christian,
>
> I've looked a bit more into this problem.
> I think the root cause is in AudioThread::ProcessControlChange()
> In particular, hSustainPtr can be set for a key that is still pressed.
> In then becomes impossible for ProcessNoteOff() to do the right thing
> . . .
>
> I tried to put these lines in AudioThread::ProcessControlChange():
>
> SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
> pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
> pMIDIKeyInfo[*key].Sustained = false;
> pMIDIKeyInfo[*key].hSustainPtr = NULL;
> into the if statement just above:
> if (!pMIDIKeyInfo[*key].KeyPressed) { // release the voices on the
> key, if the key is not pressed anymore
> so that it will not be done for keys that are still pressed.
> I gave it a very quick test and it looks like it's working correctly.
>
> Regards,
> Vladimir.
>
> PS: above is written at 2am in the morning under pressure to shut PC
> down immediately therefore it can't be trusted :)
>
> Vladimir Senkov wrote:
>
>> Christian,
>>
>> Awesome!!!
>> I can't hear any noises at all with that free Steinway sample and
>> default settings.
>>
>> But . . . I think a bug got introduced in the process.
>> Occasionally, some notes will not release completely. They'll get
>> stuck in a state where i can still hear them but their volume is
>> lower than usual.
>> If i play the same note again it goes away.
>> Kinda feels like a stuck key :) But it's not, because when i play the
>> same thing with old ls (pre cvs update) i don't get into that state.
>>
>> After a while i found a way to reproduce: (other ways may exist also)
>> 1) play and hold note. (voices: 1)
>> 2) apply and hold sustain.
>> 3) release the note (keeps playing on sustain)
>> 4) play and hold the same note again (voices: 2)
>> 4) release sustain
>> 5) apply sustain (hold)
>> 6) release the note
>> 7) release sustain. (voices: 2!)
>> Voices will still be allocated and playing at this point!
>>
>> I'd love to implement PADSDR but i hope it's not very urgent as i
>> need to do a bit of reading first.
>>
>> Regards,
>> Vladimir.
>>
>> Christian Schoenebeck wrote:
>>
>>> Changes:
>>>
>>> - There was still this annoying problem that some .gig
>>> instruments were
>>> detuned. I hope I have fixed this now. If you have still a
>>> .gig that
>>> sounds detuned, please let me know!
>>>
>>> - As promised I finished an initial version of the amplitude
>>> envelope
>>> generator (EG1), so far only a simple ASR one. Extending it
>>> to a PADSDR
>>> one (as used in Gigasampler) is quite easy. If anybody likes
>>> to do this
>>> task, you just have to improve the EG_VCA class
>>> (src/eg_vca.cpp). Vladimir
>>> perhaps?
>>> The EG has a minimum release time, in case the release time
>>> given by the
>>> gig file is 0s for example. Without this min. release time we
>>> would again
>>> have the click problem in case of zero release times when the
>>> voice will
>>> be released before it's sample end. This min. release time is
>>> defined in
>>> line 32 of src/eg_vca.h and there's another #define which
>>> sets the bottom
>>> value limit of the Exp curve, thus also defines the end of
>>> the EG curve in
>>> general. These two #define values still have to be adjusted
>>> to good values
>>>
>>> CU
>>> Christian
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Perforce Software.
>>> Perforce is the Fast Software Configuration Management System offering
>>> advanced branching capabilities and atomic changes on 50+ platforms.
>>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>>> _______________________________________________
>>> Linuxsampler-devel mailing list
>>> Lin...@li...
>>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>>
>>>
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Perforce Software.
>> Perforce is the Fast Software Configuration Management System offering
>> advanced branching capabilities and atomic changes on 50+ platforms.
>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>
>
>
>
>
> -------------------------------------------------------
> 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: Vladimir S. <ha...@so...> - 2004-01-18 06:50:04
Attachments:
adsdr.gz
|
Hi All, I've finally got around looking into enhancing EG to implement ADSDR (like Christian suggested). The intent was, again, to just support features that .gig format supports, for now. I have not implemented the preDecay1 hold yet, but it's almost there. I just need to learn a bit more about LS first to figure out how to learn if sample has been looped or not. Maybe i'll find that out tomorrow. This is the very first try, code has not been cleaned up yet, some debugging might still be left there, some comments may be extra or missing :) very limited testing was done, with just a few samples. This patch also includes the fix for "voices not going away" problem. I've also noticed that Level of preAttack was not computed correctly. I've changed all the Coeff values to be either positive or negative depending on the direction of the level, so that routine that uses Coeff to figure out the level can always add. I've moved most of that work into an inline function. It only looks like it has conditions they should be optimized out . . . Anyway, patch is attached. Please give it a try and let me know how it looks. I'll try to treat feedback on a timely manner so that it could be "ready for submit" sooner rather than later. Regards, Vladimir. |
|
From: Vladimir S. <ha...@so...> - 2004-01-18 19:27:35
Attachments:
adsdr2.gz
|
Hi All, Fixed a few issues: - if sustainlevel == 0 set it to 1. some gigs have it at 0. - some samples seem to use decay1 where they should perhaps have used decay2. so, release needs to be able to trigger during decay1 as well as decay2. For now this is what i did any objections? Attempted to add post attack hold support, but i'm not sure i did it correctly. I only have one sample with post attack hold to play with. I've used SamplePeriod (sample duration in nanoseconds) to calculate the hold time and i have doubts this because it's only 4 octets long. Seems a bit short for nanoseconds . . . If anyone could please point out what i missed there please do. Patch is not incremental, so just disregard previous patch. Regards, Vladimir. PS: still not finished work, not cleaned up, comments, etc so for testing only. |
|
From: Vladimir S. <ha...@so...> - 2004-01-18 20:13:54
Attachments:
adsdr3.gz
|
Everybody, Those two previous patches had a nasty bug, so here is another one. please disregard the other two. Sorry for too many messages. It's weekend. you'll probably not hear from me on weekdays :) Christian, Does Release coefficient have to take sustain level into consideration? It seems that it is not really necessary, but i'm not sure. Regards, Vladimir. |
|
From: Vladimir S. <ha...@so...> - 2004-01-18 20:22:07
Attachments:
adsdr4.gz
|
No, no chance of me not floodding this list today :( Left some debug in there . . . So here you go again. Vladimir Senkov wrote: > Everybody, > > Those two previous patches had a nasty bug, so here is another one. > please disregard the other two. > Sorry for too many messages. It's weekend. you'll probably not hear > from me on weekdays :) > > Christian, > Does Release coefficient have to take sustain level into consideration? > It seems that it is not really necessary, but i'm not sure. > > Regards, > Vladimir. |
|
From: Mark K. <mar...@co...> - 2004-01-18 21:08:17
|
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$ |
Thanks for helping keep SourceForge clean.
X