Menu
▾
▴
linuxsampler-devel
|
From: Robert J. <rj...@sp...> - 2004-08-25 20:04:08
|
Hi guys, Back yet from your respective vacations? :-) I tried to get linuxsampler+qsampler working tonight. So far it is less than spectacular. Compilation worked very well, launching qsampler worked aswell, but I was unable to instantiate any channels from qsampler, everytime it complained about these things: 21:56:11.257 lscp_set_channel_audio_type: There is no audio output driver 'Jack'. (errno=0) 21:56:11.261 lscp_set_channel_midi_type: There is no midi input driver 'Alsa'. (errno=0) 21:56:11.265 lscp_set_channel_midi_port: There is no MIDI input port with index 0. (errno=0) 21:56:11.284 lscp_set_channel_midi_channel: There is no MIDI input port with index 0. (errno=0) 21:56:11.302 lscp_load_instrument: No audio output device on channel (errno=0) The port names are not spelled uppercase which in later tests seems like it could be the problem. I rumaged around in the sources for a while but could not find where these come from... I had built linuxsampler from cvs and qsampler from the latest version which might account for this discrepancy? --- Anyway, having failed that I grabbed the specs and tried going from there. And got a bit further: CREATE AUDIO_OUTPUT_DEVICE JACK CREATE MIDI_INPUT_DEVICE ALSA ADD CHANNEL LOAD ENGINE GigEngine 0 SET CHANNEL AUDIO_OUTPUT_DEVICE 0 0 these worked, after this I was going to add a midi device also, but this I was unable to do. SET CHANNEL MIDI_INPUT_CHANNEL 0 0 returned that the midi port didn't exist I tried some MIDI_PORT commands also to no avail. There's something I'm missing, I'm sure... I'd be grateful for some insight. Also, a minor bug in the interpreter, even if you input a command correctly but give it the wrong arguments the interpreter still complains: Err:0:Unknown command. Which I really think should be changed to: Err:x:Bad parameter. or something similar. All for tonight, keep up the good work! /Robert -- http://spamatica.se/music/ |
|
From: Mark K. <mar...@co...> - 2004-08-25 20:30:37
|
On Wed, 2004-08-25 at 13:03, Robert Jonsson wrote: > Hi guys, Hi. > > Back yet from your respective vacations? :-) > > I tried to get linuxsampler+qsampler working tonight. So far it is less than > spectacular. Bummer... <SNIP> > I had built linuxsampler from cvs and qsampler from the latest version which > might account for this discrepancy? > I have had the best ressults from building everyting from Rui's LS page. It seems that all ends of the pipe are consistent this way. http://www.rncbc.org/ls/ |
|
From: Robert J. <rj...@sp...> - 2004-08-26 06:33:10
|
On Wednesday 25 August 2004 21.48, Mark Knecht wrote: > On Wed, 2004-08-25 at 13:03, Robert Jonsson wrote: > > Hi guys, > > Hi. > > > Back yet from your respective vacations? :-) > > > > I tried to get linuxsampler+qsampler working tonight. So far it is less > > than spectacular. > > Bummer... > <SNIP> > > > I had built linuxsampler from cvs and qsampler from the latest version > > which might account for this discrepancy? > > I have had the best ressults from building everyting from Rui's LS page. > It seems that all ends of the pipe are consistent this way. > > http://www.rncbc.org/ls/ Ah, didn't know these existed. I'll check it out later. /Robert -- http://spamatica.se/music/ |
|
From: Christian S. <sch...@so...> - 2004-08-25 22:26:10
|
Es geschah am Mittwoch, 25. August 2004 22:03 als Robert Jonsson schrieb: > Hi guys, > > Back yet from your respective vacations? :-) Jo! :) > Compilation worked very well, launching qsampler worked aswell, but I was > unable to instantiate any channels from qsampler, everytime it complained > about these things: > > 21:56:11.257 lscp_set_channel_audio_type: There is no audio output driver > 'Jack'. (errno=0) > 21:56:11.261 lscp_set_channel_midi_type: There is no midi input driver > 'Alsa'. (errno=0) > 21:56:11.265 lscp_set_channel_midi_port: There is no MIDI input port with > index 0. (errno=0) > 21:56:11.284 lscp_set_channel_midi_channel: There is no MIDI input port > with index 0. (errno=0) > 21:56:11.302 lscp_load_instrument: No audio output device on channel > (errno=0) Should already be fixed with latest CVS. > The port names are not spelled uppercase which in later tests seems like it > could be the problem. I rumaged around in the sources for a while but could > not find where these come from... > > I had built linuxsampler from cvs and qsampler from the latest version > which might account for this discrepancy? Hope it works with latest CVS, so please try again. > Anyway, having failed that I grabbed the specs and tried going from there. > And got a bit further: > > CREATE AUDIO_OUTPUT_DEVICE JACK > CREATE MIDI_INPUT_DEVICE ALSA > ADD CHANNEL > LOAD ENGINE GigEngine 0 > SET CHANNEL AUDIO_OUTPUT_DEVICE 0 0 > these worked, after this I was going to add a midi device also, but this I > was unable to do. > SET CHANNEL MIDI_INPUT_CHANNEL 0 0 > returned that the midi port didn't exist > I tried some MIDI_PORT commands also to no avail. That didn't work, because the default amount of ports was 0 by default. CREATE MIDI_INPUT_DEVICE ALSA PORTS=1 or SET MIDI_INPUT_DEVICE_PARAMETER 0 PORTS=1 after your CREATE command would have done it. But I have changed the default amount of ports to 1 now, so don't worry about that. > Also, a minor bug in the interpreter, even if you input a command correctly > but give it the wrong arguments the interpreter still complains: > Err:0:Unknown command. > > Which I really think should be changed to: > Err:x:Bad parameter. > or something similar. Yes, known. Not fixed yet due to low priority. > All for tonight, keep up the good work! Keep up testing and reporting bugs! I'll try to fix it ASAP. Thanks! CU Christian |
|
From: Christian S. <sch...@so...> - 2004-08-25 22:26:10
|
Es geschah am Mittwoch, 25. August 2004 22:03 als Robert Jonsson schrieb: > Hi guys, > > Back yet from your respective vacations? :-) Jo! :) > Compilation worked very well, launching qsampler worked aswell, but I was > unable to instantiate any channels from qsampler, everytime it complained > about these things: > > 21:56:11.257 lscp_set_channel_audio_type: There is no audio output driver > 'Jack'. (errno=0) > 21:56:11.261 lscp_set_channel_midi_type: There is no midi input driver > 'Alsa'. (errno=0) > 21:56:11.265 lscp_set_channel_midi_port: There is no MIDI input port with > index 0. (errno=0) > 21:56:11.284 lscp_set_channel_midi_channel: There is no MIDI input port > with index 0. (errno=0) > 21:56:11.302 lscp_load_instrument: No audio output device on channel > (errno=0) Should already be fixed with latest LS CVS. > The port names are not spelled uppercase which in later tests seems like it > could be the problem. I rumaged around in the sources for a while but could > not find where these come from... > > I had built linuxsampler from cvs and qsampler from the latest version > which might account for this discrepancy? Hope it works with latest LS CVS, so please try again. > Anyway, having failed that I grabbed the specs and tried going from there. > And got a bit further: > > CREATE AUDIO_OUTPUT_DEVICE JACK > CREATE MIDI_INPUT_DEVICE ALSA > ADD CHANNEL > LOAD ENGINE GigEngine 0 > SET CHANNEL AUDIO_OUTPUT_DEVICE 0 0 > these worked, after this I was going to add a midi device also, but this I > was unable to do. > SET CHANNEL MIDI_INPUT_CHANNEL 0 0 > returned that the midi port didn't exist > I tried some MIDI_PORT commands also to no avail. That didn't work, because the default amount of ports was 0 by default. CREATE MIDI_INPUT_DEVICE ALSA PORTS=1 or SET MIDI_INPUT_DEVICE_PARAMETER 0 PORTS=1 after your CREATE command would have done it. But I have changed the default amount of ports to 1 now, so don't worry about that. > Also, a minor bug in the interpreter, even if you input a command correctly > but give it the wrong arguments the interpreter still complains: > Err:0:Unknown command. > > Which I really think should be changed to: > Err:x:Bad parameter. > or something similar. Yes, known. Not fixed yet due to low priority. > All for tonight, keep up the good work! Keep up testing and reporting bugs! I'll try to fix it ASAP. Thanks! CU Christian |
|
From: Robert J. <rob...@da...> - 2004-08-26 06:36:46
|
On Thursday 26 August 2004 00.17, Christian Schoenebeck wrote: > Es geschah am Mittwoch, 25. August 2004 22:03 als Robert Jonsson schrieb: > > Hi guys, > > > > Back yet from your respective vacations? :-) > > Jo! :) Jaha ;) > > > Compilation worked very well, launching qsampler worked aswell, but I was > > unable to instantiate any channels from qsampler, everytime it complained > > about these things: > > > > 21:56:11.257 lscp_set_channel_audio_type: There is no audio output driver > > 'Jack'. (errno=0) > > 21:56:11.261 lscp_set_channel_midi_type: There is no midi input driver > > 'Alsa'. (errno=0) > > 21:56:11.265 lscp_set_channel_midi_port: There is no MIDI input port with > > index 0. (errno=0) > > 21:56:11.284 lscp_set_channel_midi_channel: There is no MIDI input port > > with index 0. (errno=0) > > 21:56:11.302 lscp_load_instrument: No audio output device on channel > > (errno=0) > > Should already be fixed with latest CVS. Ah, nice, a new checkin! :) I'll try this too later. > > > The port names are not spelled uppercase which in later tests seems like > > it could be the problem. I rumaged around in the sources for a while but > > could not find where these come from... > > > > I had built linuxsampler from cvs and qsampler from the latest version > > which might account for this discrepancy? > > Hope it works with latest CVS, so please try again. > > > Anyway, having failed that I grabbed the specs and tried going from > > there. And got a bit further: > > > > CREATE AUDIO_OUTPUT_DEVICE JACK > > CREATE MIDI_INPUT_DEVICE ALSA > > ADD CHANNEL > > LOAD ENGINE GigEngine 0 > > SET CHANNEL AUDIO_OUTPUT_DEVICE 0 0 > > these worked, after this I was going to add a midi device also, but this > > I was unable to do. > > SET CHANNEL MIDI_INPUT_CHANNEL 0 0 > > returned that the midi port didn't exist > > I tried some MIDI_PORT commands also to no avail. > > That didn't work, because the default amount of ports was 0 by default. > > CREATE MIDI_INPUT_DEVICE ALSA PORTS=1 > > or > > SET MIDI_INPUT_DEVICE_PARAMETER 0 PORTS=1 > > after your CREATE command would have done it. But I have changed the > default amount of ports to 1 now, so don't worry about that. Ah, thanks for the explanation, will get me a bit further. /Robert |
|
From: Robert J. <rj...@sp...> - 2004-08-29 12:41:46
|
> > after your CREATE command would have done it. But I have changed the > > default amount of ports to 1 now, so don't worry about that. > > Ah, thanks for the explanation, will get me a bit further. Hi again, Got it to work eventually, not entirely stable but not bad either. Current problem is that I only seem able to select patch 0. Is this expected with the current version or am I missing something? /Robert -- http://spamatica.se/music/ |
|
From: Christian S. <sch...@so...> - 2004-08-29 13:44:24
Attachments:
example_with_alsa.lscp
example_with_jack.lscp
|
Es geschah am Sonntag, 29. August 2004 14:41 als Robert Jonsson schrieb: > Got it to work eventually, not entirely stable but not bad either. Current > problem is that I only seem able to select patch 0. Is this expected with > the current version or am I missing something? You should be able to select any instrument from a .gig file. Maybe you're referring to the GUI behavior? Actually the GUI works with current LS CVS, but it doesn't display channel informations correctly at this point. For those of you who prefer ro run LS entirely on the console and don't want to read the whole LSCP doc, I attached two example LSCP scripts which show how to setup a LS session (including automatic connection to other JACK clients and ALSA sequencer clients). Both scripts setup only one sampler channel, but extending them to multiple sampler channels should be trivial for you. As always use e.g. 'cat yourscript.lscp | netcat -t localhost 8888' to send the script to the running LinuxSampler instance. CU Christian |
|
From: Robert J. <rj...@sp...> - 2004-08-29 20:56:10
|
s=F6ndagen den 29 augusti 2004 15.35 skrev Christian Schoenebeck:
> Es geschah am Sonntag, 29. August 2004 14:41 als Robert Jonsson schrieb:
> > Got it to work eventually, not entirely stable but not bad either.
> > Current problem is that I only seem able to select patch 0. Is this
> > expected with the current version or am I missing something?
>
> You should be able to select any instrument from a .gig file. Maybe you're
> referring to the GUI behavior?=20
Ah, yes, silly of me. I was indeed mostly trying the GUI and getting a bit=
=20
confused with naming conventions and things.
I got it working finally, lovely! Still a bit to go but=20
getting closer all the time ;).
As you might know the thing I'm trying to get to work right now is Drumkit=
=20
from Hell. First I note that linuxsampler takes 204mb of memory when loadin=
g=20
both the close and rear micked kits. Instinctively it's a bit much but then=
=20
again there are alot of samples...
I got it to crash quite easilt also, just playing this setup, I will=20
investigate this more.=20
I also had X vanish a few times while testing linuxsampler. My guess is tha=
t=20
linuxsampler gets kicked/crashes from jack, jack freezes qjackctl, somethin=
g=20
bad happens, qjackctl-->X-->poof.
Ahh, here's a backtrace of one of the crashes, seems mostly unusable though=
,=20
optimized binary I presume, I will compile for debug later:
(gdb) bt
#0 LinuxSampler::gig::EGADSR::Process(unsigned,=20
RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double)=20
(this=3DVariable "this" is not available.
) at EGADSR.cpp:151
#1 0x400a073f in LinuxSampler::gig::Voice::Render(unsigned) (this=3DVariab=
le=20
"this" is not available.
) at Voice.cpp:529
#2 0x400945ad in LinuxSampler::gig::Engine::RenderAudio(unsigned)=20
(this=3D0x80608d8,
Samples=3D512) at Engine.cpp:433
#3 0x400bfffe in LinuxSampler::AudioOutputDevice::RenderAudio(unsigned)=20
(this=3D0x80511c0,
Samples=3D512) at AudioOutputDevice.cpp:251
#4 0x400d1b8b in LinuxSampler::AudioOutputDeviceJack::Process(unsigned)=20
(this=3DVariable "this" is not available.
)
at AudioOutputDeviceJack.cpp:155
#5 0x400d1fc4 in LinuxSampler::__libjack_process_callback(unsigned, void*)=
=20
(nframes=3DVariable "nframes" is not available.
)
at AudioOutputDeviceJack.cpp:208
#6 0x40142566 in jack_stop_freewheel () from /usr/lib/libjack.so.0
#7 0x00000200 in ?? ()
#8 0x080511c0 in ?? ()
#9 0x000005ba in ?? ()
=2D--
As for drum specific things, it is common in drumbanks to have the hihat on=
=20
several keys (as is the case here too), since a hihat is monophonic by natu=
re=20
these keys are often grouped together so only one of them can produce sound=
=20
at the time.
This does not seem to be the case here, I have no idea how things like this=
=20
work with GIG files or if it is at all possible or if the bank infact is=20
programmed for this. But my gut feeling is that it should be possible and=20
that the bank should support it.
The remaining question is then: Is it known how this works in the file form=
at=20
and is it implementable?
There are other ways to solve this so I'm not stranded but it would be good=
to=20
know if this might work later on.
I noticed the ECHO ON in the script which is a good thing indeed. Would it =
be=20
possible to extend this to outputting text in the terminal on the server si=
de=20
also?
I'm not sure if it's the right way to do it but I imagine it would be quite=
=20
usable for debugging when running the GUI and linuxsampler in separate=20
terminals. I would for sure have liked it while trying to get the GUI to=20
dance.
All for now, keep up the good work!
/Robert
=2D-=20
http://spamatica.se/music/
|
|
From: Christian S. <sch...@so...> - 2004-09-01 05:17:13
|
Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb: > Ahh, here's a backtrace of one of the crashes, seems mostly unusable > though, optimized binary I presume, I will compile for debug later: > > (gdb) bt > #0 LinuxSampler::gig::EGADSR::Process(unsigned, > RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) > (this=Variable "this" is not available. > ) at EGADSR.cpp:151 Seems it went beyond the boundaries of the synthesis parameters matrix which resulted in a segfault of course. That one has to be investigated. You didn't change any important JACK setting while running it, did you? Because LS's JACK driver currently doesn't react on such changes. > As for drum specific things, it is common in drumbanks to have the hihat on > several keys (as is the case here too), since a hihat is monophonic by > nature these keys are often grouped together so only one of them can > produce sound at the time. Yes, libgig reads and offers sample group informations (see gig.h, line 458), but these informations are not yet used by the gig engine. This is an important feature that has to be implemented. > I noticed the ECHO ON in the script which is a good thing indeed. Would it > be possible to extend this to outputting text in the terminal on the server > side also? > I'm not sure if it's the right way to do it but I imagine it would be quite > usable for debugging when running the GUI and linuxsampler in separate > terminals. I would for sure have liked it while trying to get the GUI to > dance. Agreed, could be quite handy for debugging the GUI. CU Christian P.S. sorry for the late response |
|
From: Robert J. <rj...@sp...> - 2004-09-01 10:03:23
|
On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote: > Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb: > > Ahh, here's a backtrace of one of the crashes, seems mostly unusable > > though, optimized binary I presume, I will compile for debug later: > > > > (gdb) bt > > #0 LinuxSampler::gig::EGADSR::Process(unsigned, > > RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) > > (this=Variable "this" is not available. > > ) at EGADSR.cpp:151 > > Seems it went beyond the boundaries of the synthesis parameters matrix > which resulted in a segfault of course. That one has to be investigated. > You didn't change any important JACK setting while running it, did you? > Because LS's JACK driver currently doesn't react on such changes. To my knowledge the only think I did was hitting keys on the midi-keyboard. > > > As for drum specific things, it is common in drumbanks to have the hihat > > on several keys (as is the case here too), since a hihat is monophonic by > > nature these keys are often grouped together so only one of them can > > produce sound at the time. > > Yes, libgig reads and offers sample group informations (see gig.h, line > 458), but these informations are not yet used by the gig engine. This is an > important feature that has to be implemented. Ah, cool. > > > I noticed the ECHO ON in the script which is a good thing indeed. Would > > it be possible to extend this to outputting text in the terminal on the > > server side also? > > I'm not sure if it's the right way to do it but I imagine it would be > > quite usable for debugging when running the GUI and linuxsampler in > > separate terminals. I would for sure have liked it while trying to get > > the GUI to dance. > > Agreed, could be quite handy for debugging the GUI. > > CU > Christian > > P.S. sorry for the late response No problem at all. /Robert -- http://spamatica.se/music/ |
|
From: Vladimir S. <ha...@so...> - 2004-09-12 02:06:39
|
Hi Robert, I've just checked something in, could you try to reproduce this problem with the latest cvs? I think there was a problem in Process() method in some states it was checking if the events fragment position is beyond the matrix while in some cases it wasn't. So i've made a change to always check that. I was getting a crash that may have been the same as yours but now i'm not getting it anymore. Our configs are different though (for one thing i was not using jack when i was getting those cores) so i'm not sure the root cause is the same . . . so please give it a try. Regards, Vladimir. Robert Jonsson wrote: >On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote: > > >>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb: >> >> >>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable >>>though, optimized binary I presume, I will compile for debug later: >>> >>>(gdb) bt >>>#0 LinuxSampler::gig::EGADSR::Process(unsigned, >>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) >>>(this=Variable "this" is not available. >>>) at EGADSR.cpp:151 >>> >>> >>Seems it went beyond the boundaries of the synthesis parameters matrix >>which resulted in a segfault of course. That one has to be investigated. >>You didn't change any important JACK setting while running it, did you? >>Because LS's JACK driver currently doesn't react on such changes. >> >> > >To my knowledge the only think I did was hitting keys on the midi-keyboard. > > > >>>As for drum specific things, it is common in drumbanks to have the hihat >>>on several keys (as is the case here too), since a hihat is monophonic by >>>nature these keys are often grouped together so only one of them can >>>produce sound at the time. >>> >>> >>Yes, libgig reads and offers sample group informations (see gig.h, line >>458), but these informations are not yet used by the gig engine. This is an >>important feature that has to be implemented. >> >> > >Ah, cool. > > > >>>I noticed the ECHO ON in the script which is a good thing indeed. Would >>>it be possible to extend this to outputting text in the terminal on the >>>server side also? >>>I'm not sure if it's the right way to do it but I imagine it would be >>>quite usable for debugging when running the GUI and linuxsampler in >>>separate terminals. I would for sure have liked it while trying to get >>>the GUI to dance. >>> >>> >>Agreed, could be quite handy for debugging the GUI. >> >>CU >>Christian >> >>P.S. sorry for the late response >> >> > >No problem at all. > >/Robert > > > > |
|
From: Robert J. <rj...@sp...> - 2004-09-20 18:34:07
|
Hi, s=F6ndagen den 12 september 2004 04.06 skrev Vladimir Senkov: > Hi Robert, > > I've just checked something in, could you try to reproduce this problem > with the latest cvs? Long response times here, sorry. I'll try to hammer away at this a bit=20 tonight, will see what happens. /Robert > I think there was a problem in Process() method in some states it was > checking if the events fragment position is beyond the matrix while in > some cases it wasn't. So i've made a change to always check that. > I was getting a crash that may have been the same as yours but now i'm > not getting it anymore. Our configs are different though (for one thing > i was not using jack when i was getting those cores) so i'm not sure the > root cause is the same . . . so please give it a try. > > Regards, > Vladimir. > > Robert Jonsson wrote: > >On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote: > >>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb: > >>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable > >>>though, optimized binary I presume, I will compile for debug later: > >>> > >>>(gdb) bt > >>>#0 LinuxSampler::gig::EGADSR::Process(unsigned, > >>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) > >>>(this=3DVariable "this" is not available. > >>>) at EGADSR.cpp:151 > >> > >>Seems it went beyond the boundaries of the synthesis parameters matrix > >>which resulted in a segfault of course. That one has to be investigated. > >>You didn't change any important JACK setting while running it, did you? > >>Because LS's JACK driver currently doesn't react on such changes. > > > >To my knowledge the only think I did was hitting keys on the > > midi-keyboard. > > > >>>As for drum specific things, it is common in drumbanks to have the hih= at > >>>on several keys (as is the case here too), since a hihat is monophonic > >>> by nature these keys are often grouped together so only one of them c= an > >>> produce sound at the time. > >> > >>Yes, libgig reads and offers sample group informations (see gig.h, line > >>458), but these informations are not yet used by the gig engine. This is > >> an important feature that has to be implemented. > > > >Ah, cool. > > > >>>I noticed the ECHO ON in the script which is a good thing indeed. Would > >>>it be possible to extend this to outputting text in the terminal on the > >>>server side also? > >>>I'm not sure if it's the right way to do it but I imagine it would be > >>>quite usable for debugging when running the GUI and linuxsampler in > >>>separate terminals. I would for sure have liked it while trying to get > >>>the GUI to dance. > >> > >>Agreed, could be quite handy for debugging the GUI. > >> > >>CU > >>Christian > >> > >>P.S. sorry for the late response > > > >No problem at all. > > > >/Robert > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel =2D-=20 http://spamatica.se/music/ |
|
From: Robert J. <rj...@sp...> - 2004-09-21 19:27:06
|
m=E5ndagen den 20 september 2004 20.33 skrev Robert Jonsson: > Hi, > > s=F6ndagen den 12 september 2004 04.06 skrev Vladimir Senkov: > > Hi Robert, > > > > I've just checked something in, could you try to reproduce this problem > > with the latest cvs? > > Long response times here, sorry. I'll try to hammer away at this a bit > tonight, will see what happens. Ack, bad times... I didn't even manage to get any sound at all. I've used u= p=20 my timeslice for a few more days so I will likely don't have anything to sa= y=20 for a while. Looking forward to test the grouping also! /Robert > > /Robert > > > I think there was a problem in Process() method in some states it was > > checking if the events fragment position is beyond the matrix while in > > some cases it wasn't. So i've made a change to always check that. > > I was getting a crash that may have been the same as yours but now i'm > > not getting it anymore. Our configs are different though (for one thing > > i was not using jack when i was getting those cores) so i'm not sure the > > root cause is the same . . . so please give it a try. > > > > Regards, > > Vladimir. > > > > Robert Jonsson wrote: > > >On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote: > > >>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schri= eb: > > >>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable > > >>>though, optimized binary I presume, I will compile for debug later: > > >>> > > >>>(gdb) bt > > >>>#0 LinuxSampler::gig::EGADSR::Process(unsigned, > > >>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) > > >>>(this=3DVariable "this" is not available. > > >>>) at EGADSR.cpp:151 > > >> > > >>Seems it went beyond the boundaries of the synthesis parameters matrix > > >>which resulted in a segfault of course. That one has to be > > >> investigated. You didn't change any important JACK setting while > > >> running it, did you? Because LS's JACK driver currently doesn't react > > >> on such changes. > > > > > >To my knowledge the only think I did was hitting keys on the > > > midi-keyboard. > > > > > >>>As for drum specific things, it is common in drumbanks to have the > > >>> hihat on several keys (as is the case here too), since a hihat is > > >>> monophonic by nature these keys are often grouped together so only > > >>> one of them can produce sound at the time. > > >> > > >>Yes, libgig reads and offers sample group informations (see gig.h, li= ne > > >>458), but these informations are not yet used by the gig engine. This > > >> is an important feature that has to be implemented. > > > > > >Ah, cool. > > > > > >>>I noticed the ECHO ON in the script which is a good thing indeed. > > >>> Would it be possible to extend this to outputting text in the > > >>> terminal on the server side also? > > >>>I'm not sure if it's the right way to do it but I imagine it would be > > >>>quite usable for debugging when running the GUI and linuxsampler in > > >>>separate terminals. I would for sure have liked it while trying to g= et > > >>>the GUI to dance. > > >> > > >>Agreed, could be quite handy for debugging the GUI. > > >> > > >>CU > > >>Christian > > >> > > >>P.S. sorry for the late response > > > > > >No problem at all. > > > > > >/Robert > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel =2D-=20 http://spamatica.se/music/ |
|
From: Vladimir S. <ha...@so...> - 2004-09-21 21:05:20
|
Hi Robert, Please make sure you're running the latest LS. I've made a check-in a few days ago that fixed a small problem with panning that caused LS to be silent. I'm hoping it's the same problem you have at the moment so things should be working again once you take an update from cvs. Sorry about that, bad timing :( It is usually a good idea to visit the news page on the LS website to see if there were any recent updates to the code that might fix an issue (if you have any). We try to put descriptive notes there to make it easier to figure out if it's the same problem or not. Regards, Vladimir. Robert Jonsson wrote: >måndagen den 20 september 2004 20.33 skrev Robert Jonsson: > > >>Hi, >> >>söndagen den 12 september 2004 04.06 skrev Vladimir Senkov: >> >> >>>Hi Robert, >>> >>>I've just checked something in, could you try to reproduce this problem >>>with the latest cvs? >>> >>> >>Long response times here, sorry. I'll try to hammer away at this a bit >>tonight, will see what happens. >> >> > >Ack, bad times... I didn't even manage to get any sound at all. I've used up >my timeslice for a few more days so I will likely don't have anything to say >for a while. > >Looking forward to test the grouping also! > >/Robert > > > >>/Robert >> >> >> >>>I think there was a problem in Process() method in some states it was >>>checking if the events fragment position is beyond the matrix while in >>>some cases it wasn't. So i've made a change to always check that. >>>I was getting a crash that may have been the same as yours but now i'm >>>not getting it anymore. Our configs are different though (for one thing >>>i was not using jack when i was getting those cores) so i'm not sure the >>>root cause is the same . . . so please give it a try. >>> >>>Regards, >>>Vladimir. >>> >>>Robert Jonsson wrote: >>> >>> >>>>On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote: >>>> >>>> >>>>>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson schrieb: >>>>> >>>>> >>>>>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable >>>>>>though, optimized binary I presume, I will compile for debug later: >>>>>> >>>>>>(gdb) bt >>>>>>#0 LinuxSampler::gig::EGADSR::Process(unsigned, >>>>>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) >>>>>>(this=Variable "this" is not available. >>>>>>) at EGADSR.cpp:151 >>>>>> >>>>>> >>>>>Seems it went beyond the boundaries of the synthesis parameters matrix >>>>>which resulted in a segfault of course. That one has to be >>>>>investigated. You didn't change any important JACK setting while >>>>>running it, did you? Because LS's JACK driver currently doesn't react >>>>>on such changes. >>>>> >>>>> >>>>To my knowledge the only think I did was hitting keys on the >>>>midi-keyboard. >>>> >>>> >>>> >>>>>>As for drum specific things, it is common in drumbanks to have the >>>>>>hihat on several keys (as is the case here too), since a hihat is >>>>>>monophonic by nature these keys are often grouped together so only >>>>>>one of them can produce sound at the time. >>>>>> >>>>>> >>>>>Yes, libgig reads and offers sample group informations (see gig.h, line >>>>>458), but these informations are not yet used by the gig engine. This >>>>>is an important feature that has to be implemented. >>>>> >>>>> >>>>Ah, cool. >>>> >>>> >>>> >>>>>>I noticed the ECHO ON in the script which is a good thing indeed. >>>>>>Would it be possible to extend this to outputting text in the >>>>>>terminal on the server side also? >>>>>>I'm not sure if it's the right way to do it but I imagine it would be >>>>>>quite usable for debugging when running the GUI and linuxsampler in >>>>>>separate terminals. I would for sure have liked it while trying to get >>>>>>the GUI to dance. >>>>>> >>>>>> >>>>>Agreed, could be quite handy for debugging the GUI. >>>>> >>>>>CU >>>>>Christian >>>>> >>>>>P.S. sorry for the late response >>>>> >>>>> >>>>No problem at all. >>>> >>>>/Robert >>>> >>>> >>>------------------------------------------------------- >>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >>>Project Admins to receive an Apple iPod Mini FREE for your judgement on >>>who ports your project to Linux PPC the best. Sponsored by IBM. >>>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php >>>_______________________________________________ >>>Linuxsampler-devel mailing list >>>Lin...@li... >>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >>> >>> > > > |
|
From: Robert J. <rj...@sp...> - 2004-09-21 21:45:37
|
Hi guys, tisdagen den 21 september 2004 23.04 skrev Vladimir Senkov: > Hi Robert, > > Please make sure you're running the latest LS. I've made a check-in a > few days ago that fixed a small problem with panning that caused LS to > be silent. I'm hoping it's the same problem you have at the moment so > things should be working again once you take an update from cvs. > Sorry about that, bad timing :( Actually I had updated the tree. I had me a doze of inspiration and started poking at it again. And as it=20 happens I was trying the wrong startup script (I am curently not running=20 through the GUI)...sorry... I think I'm a little over worked ;)... As for the crash bug, I haven't seen it... though I didn't play that long.= =20 Seems solid enough.=20 I noticed the grouping has started to work also. Great! Atleast on some of = the=20 samples. I have to check with that GIG utility what samples really are in t= he=20 group, probably it's correct but I think there should be more of them. Also, I have new headphones...don't know if it's that or if it's been there= =20 all along but I'm starting to hear artifacts in the sound. Clicking at the= =20 end of the samples... and some very strange sound when "shutting of" a long= =20 sound with a short one (in a group). I will try to record some examples so= =20 you can hear what I'm trying to describe. Not tonight though. /Robert > It is usually a good idea to visit the news page on the LS website to > see if there were any recent updates to the code that might fix an issue > (if you have any). We try to put descriptive notes there to make it > easier to figure out if it's the same problem or not. > > Regards, > Vladimir. > > Robert Jonsson wrote: > >m=E5ndagen den 20 september 2004 20.33 skrev Robert Jonsson: > >>Hi, > >> > >>s=F6ndagen den 12 september 2004 04.06 skrev Vladimir Senkov: > >>>Hi Robert, > >>> > >>>I've just checked something in, could you try to reproduce this problem > >>>with the latest cvs? > >> > >>Long response times here, sorry. I'll try to hammer away at this a bit > >>tonight, will see what happens. > > > >Ack, bad times... I didn't even manage to get any sound at all. I've used > > up my timeslice for a few more days so I will likely don't have anything > > to say for a while. > > > >Looking forward to test the grouping also! > > > >/Robert > > > >>/Robert > >> > >>>I think there was a problem in Process() method in some states it was > >>>checking if the events fragment position is beyond the matrix while in > >>>some cases it wasn't. So i've made a change to always check that. > >>>I was getting a crash that may have been the same as yours but now i'm > >>>not getting it anymore. Our configs are different though (for one thing > >>>i was not using jack when i was getting those cores) so i'm not sure t= he > >>>root cause is the same . . . so please give it a try. > >>> > >>>Regards, > >>>Vladimir. > >>> > >>>Robert Jonsson wrote: > >>>>On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote: > >>>>>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson=20 schrieb: > >>>>>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable > >>>>>>though, optimized binary I presume, I will compile for debug later: > >>>>>> > >>>>>>(gdb) bt > >>>>>>#0 LinuxSampler::gig::EGADSR::Process(unsigned, > >>>>>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) > >>>>>>(this=3DVariable "this" is not available. > >>>>>>) at EGADSR.cpp:151 > >>>>> > >>>>>Seems it went beyond the boundaries of the synthesis parameters matr= ix > >>>>>which resulted in a segfault of course. That one has to be > >>>>>investigated. You didn't change any important JACK setting while > >>>>>running it, did you? Because LS's JACK driver currently doesn't react > >>>>>on such changes. > >>>> > >>>>To my knowledge the only think I did was hitting keys on the > >>>>midi-keyboard. > >>>> > >>>>>>As for drum specific things, it is common in drumbanks to have the > >>>>>>hihat on several keys (as is the case here too), since a hihat is > >>>>>>monophonic by nature these keys are often grouped together so only > >>>>>>one of them can produce sound at the time. > >>>>> > >>>>>Yes, libgig reads and offers sample group informations (see gig.h, > >>>>> line 458), but these informations are not yet used by the gig engin= e. > >>>>> This is an important feature that has to be implemented. > >>>> > >>>>Ah, cool. > >>>> > >>>>>>I noticed the ECHO ON in the script which is a good thing indeed. > >>>>>>Would it be possible to extend this to outputting text in the > >>>>>>terminal on the server side also? > >>>>>>I'm not sure if it's the right way to do it but I imagine it would = be > >>>>>>quite usable for debugging when running the GUI and linuxsampler in > >>>>>>separate terminals. I would for sure have liked it while trying to > >>>>>> get the GUI to dance. > >>>>> > >>>>>Agreed, could be quite handy for debugging the GUI. > >>>>> > >>>>>CU > >>>>>Christian > >>>>> > >>>>>P.S. sorry for the late response > >>>> > >>>>No problem at all. > >>>> > >>>>/Robert > >>> > >>>------------------------------------------------------- > >>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > >>>Project Admins to receive an Apple iPod Mini FREE for your judgement on > >>>who ports your project to Linux PPC the best. Sponsored by IBM. > >>>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > >>>_______________________________________________ > >>>Linuxsampler-devel mailing list > >>>Lin...@li... > >>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel =2D-=20 http://spamatica.se/music/ |
|
From: Vladimir S. <ha...@so...> - 2004-09-21 22:21:19
|
Hi Robert, I think the clicking you are hearing is related to the voice stealing work that Christian has just put in, it is still work in progress . . . as such he had to tweak a few things in the envelope generator (for the time being). So your headphones are probably fine :) Regards, Vladimir. Robert Jonsson wrote: >Hi guys, > >tisdagen den 21 september 2004 23.04 skrev Vladimir Senkov: > > >>Hi Robert, >> >>Please make sure you're running the latest LS. I've made a check-in a >>few days ago that fixed a small problem with panning that caused LS to >>be silent. I'm hoping it's the same problem you have at the moment so >>things should be working again once you take an update from cvs. >>Sorry about that, bad timing :( >> >> > >Actually I had updated the tree. >I had me a doze of inspiration and started poking at it again. And as it >happens I was trying the wrong startup script (I am curently not running >through the GUI)...sorry... I think I'm a little over worked ;)... > >As for the crash bug, I haven't seen it... though I didn't play that long. >Seems solid enough. >I noticed the grouping has started to work also. Great! Atleast on some of the >samples. I have to check with that GIG utility what samples really are in the >group, probably it's correct but I think there should be more of them. > >Also, I have new headphones...don't know if it's that or if it's been there >all along but I'm starting to hear artifacts in the sound. Clicking at the >end of the samples... and some very strange sound when "shutting of" a long >sound with a short one (in a group). I will try to record some examples so >you can hear what I'm trying to describe. Not tonight though. > >/Robert > > > >>It is usually a good idea to visit the news page on the LS website to >>see if there were any recent updates to the code that might fix an issue >>(if you have any). We try to put descriptive notes there to make it >>easier to figure out if it's the same problem or not. >> >>Regards, >>Vladimir. >> >>Robert Jonsson wrote: >> >> >>>måndagen den 20 september 2004 20.33 skrev Robert Jonsson: >>> >>> >>>>Hi, >>>> >>>>söndagen den 12 september 2004 04.06 skrev Vladimir Senkov: >>>> >>>> >>>>>Hi Robert, >>>>> >>>>>I've just checked something in, could you try to reproduce this problem >>>>>with the latest cvs? >>>>> >>>>> >>>>Long response times here, sorry. I'll try to hammer away at this a bit >>>>tonight, will see what happens. >>>> >>>> >>>Ack, bad times... I didn't even manage to get any sound at all. I've used >>>up my timeslice for a few more days so I will likely don't have anything >>>to say for a while. >>> >>>Looking forward to test the grouping also! >>> >>>/Robert >>> >>> >>> >>>>/Robert >>>> >>>> >>>> >>>>>I think there was a problem in Process() method in some states it was >>>>>checking if the events fragment position is beyond the matrix while in >>>>>some cases it wasn't. So i've made a change to always check that. >>>>>I was getting a crash that may have been the same as yours but now i'm >>>>>not getting it anymore. Our configs are different though (for one thing >>>>>i was not using jack when i was getting those cores) so i'm not sure the >>>>>root cause is the same . . . so please give it a try. >>>>> >>>>>Regards, >>>>>Vladimir. >>>>> >>>>>Robert Jonsson wrote: >>>>> >>>>> >>>>>>On Tuesday 31 August 2004 22.44, Christian Schoenebeck wrote: >>>>>> >>>>>> >>>>>>>Es geschah am Sonntag, 29. August 2004 22:55 als Robert Jonsson >>>>>>> >>>>>>> >schrieb: > > >>>>>>>>Ahh, here's a backtrace of one of the crashes, seems mostly unusable >>>>>>>>though, optimized binary I presume, I will compile for debug later: >>>>>>>> >>>>>>>>(gdb) bt >>>>>>>>#0 LinuxSampler::gig::EGADSR::Process(unsigned, >>>>>>>>RTEList<LinuxSampler::Event>*, LinuxSampler::Event*, double, double) >>>>>>>>(this=Variable "this" is not available. >>>>>>>>) at EGADSR.cpp:151 >>>>>>>> >>>>>>>> >>>>>>>Seems it went beyond the boundaries of the synthesis parameters matrix >>>>>>>which resulted in a segfault of course. That one has to be >>>>>>>investigated. You didn't change any important JACK setting while >>>>>>>running it, did you? Because LS's JACK driver currently doesn't react >>>>>>>on such changes. >>>>>>> >>>>>>> >>>>>>To my knowledge the only think I did was hitting keys on the >>>>>>midi-keyboard. >>>>>> >>>>>> >>>>>> >>>>>>>>As for drum specific things, it is common in drumbanks to have the >>>>>>>>hihat on several keys (as is the case here too), since a hihat is >>>>>>>>monophonic by nature these keys are often grouped together so only >>>>>>>>one of them can produce sound at the time. >>>>>>>> >>>>>>>> >>>>>>>Yes, libgig reads and offers sample group informations (see gig.h, >>>>>>>line 458), but these informations are not yet used by the gig engine. >>>>>>>This is an important feature that has to be implemented. >>>>>>> >>>>>>> >>>>>>Ah, cool. >>>>>> >>>>>> >>>>>> >>>>>>>>I noticed the ECHO ON in the script which is a good thing indeed. >>>>>>>>Would it be possible to extend this to outputting text in the >>>>>>>>terminal on the server side also? >>>>>>>>I'm not sure if it's the right way to do it but I imagine it would be >>>>>>>>quite usable for debugging when running the GUI and linuxsampler in >>>>>>>>separate terminals. I would for sure have liked it while trying to >>>>>>>>get the GUI to dance. >>>>>>>> >>>>>>>> >>>>>>>Agreed, could be quite handy for debugging the GUI. >>>>>>> >>>>>>>CU >>>>>>>Christian >>>>>>> >>>>>>>P.S. sorry for the late response >>>>>>> >>>>>>> >>>>>>No problem at all. >>>>>> >>>>>>/Robert >>>>>> >>>>>> >>>>>------------------------------------------------------- >>>>>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >>>>>Project Admins to receive an Apple iPod Mini FREE for your judgement on >>>>>who ports your project to Linux PPC the best. Sponsored by IBM. >>>>>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php >>>>>_______________________________________________ >>>>>Linuxsampler-devel mailing list >>>>>Lin...@li... >>>>>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >>>>> >>>>> >>------------------------------------------------------- >>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >>Project Admins to receive an Apple iPod Mini FREE for your judgement on >>who ports your project to Linux PPC the best. Sponsored by IBM. >>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >>_______________________________________________ >>Linuxsampler-devel mailing list >>Lin...@li... >>https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel >> >> > > > |
|
From: Christian S. <sch...@so...> - 2004-09-22 09:36:32
|
Es geschah am Mittwoch 22 September 2004 00:20 als Vladimir Senkov schrieb: > I think the clicking you are hearing is related to the voice stealing > work that Christian has just put in, it is still work in progress . . . > as such he had to tweak a few things in the envelope generator (for the > time being). > So your headphones are probably fine :) [snip] > >Also, I have new headphones...don't know if it's that or if it's been > > there all along but I'm starting to hear artifacts in the sound. Clicking > > at the end of the samples... and some very strange sound when "shutting > > of" a long sound with a short one (in a group). I will try to record some > > examples so you can hear what I'm trying to describe. Not tonight though. Thought I had fixed this on monday. Please make sure you have the latest version. Otherwise, what sample rate and buffer size do you use with your sound card? If you really hear click sounds with latest CVS then try to play with the EG_MIN_RELEASE_TIME value in /src/engines/gig/EGADSR.h. This value defines the minimum time (in seconds) to fade down a voice to zero level. If this value is too small, then you'll hear click sounds. But note: this value has always to be smaller than the duration of your audio fragment. Example: You use a buffer size of 128 sample points and a sample rate of 44100kHz with your sound card, so the duration time of one audio fragment would be: 128 / 44100 = 0.0029 So EG_MIN_RELEASE_TIME should be smaller than 0.0029 in this case. If this value is too high, then the voice stealing algorithm won't work, because it tries to fade down voices and steal them within the same audio fragment. CU Christian |
Thanks for helping keep SourceForge clean.
X