12 Jan
2010
12 Jan
'10
3:26 p.m.
The main change in 0.051 is to the recorder start logic, which sort of goes like -
- Select your wav file, and the recorder becomes armed.
- When armed, recording starts with the first note-on event, or a click on
the Record button.
- When armed, a click on the Stop button disarms the recorder.
- When recording, a click on the Stop button stops the recorder, leaving it
armed.
<http://sourceforge.net/projects/yoshimi/files/>
Bon apetit.
cheers, Cal
12 Jan
12 Jan
11:47 p.m.
On Tue, Jan 12, 2010 at 8:26 PM, cal wrote:
The main change in 0.051 is to the recorder start
logic, which sort of goes like -
- Select your wav file, and the recorder becomes armed.
- When armed, recording starts with the first note-on event, or a click on
the Record button.
- When armed, a click on the Stop button disarms the recorder.
- When recording, a click on the Stop button stops the recorder, leaving it
armed.
<http://sourceforge.net/projects/yoshimi/files/>
The sourceforge link seems to be outdated, still on version 0.047.1.
No problen, good old
http://www.graggrag.com/?q=node/19
is up to date.
A build error:
/home/abs/yoshimi/src/yoshimi-0.051/src/MasterUI.h:28:24: error:
fltk/Color.h: No such file or directory
[...]
Aborting...
installing fltk2 resolved it.
Next, on startup:
$ yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/user/.zynaddsubfxXML.cfg could not be loaded or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
I found a .zynaddsubfxXML.cfg online from trinity. With that it
worked, though with an unusual layout.
I unsuccessfully looked for other .cfg files to use (using google
and searching zynadd 2.4.0/zynadd git). I'd love to have
one that gives the old layout.
The whole story is the same with yoshimi 0.052-pre1
Thanks for zyn, thanks again for yoshimi,
best,
d
Bon apetit.
thanks, tasty miso soup on my table :)
13 Jan
13 Jan
1:10 a.m.
Hello all,
Same problem over here, after installing fltk2 the fltk/Color.h problem was
solved and it installed correctly.
Now on the startup stage I'm getting this error, which seems to be related
to jack or midi setup:
Error, failed to start jack midi thread: 1
So sad, failed to start MusicIO
***** here's the entire output:
diego@diego-laptop:~$ /usr/bin/jackd -dalsa -dhw:0,0 -r44100 -p1024 -n2 &
[1] 8456
diego@diego-laptop:~$ no message buffer overruns
jackd 0.116.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
SSE2 detected
apparent rate = 44100
creating alsa driver ...
hw:0,0|hw:0,0|1024|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
diego@diego-laptop:~$
diego@diego-laptop:~$
diego@diego-laptop:~$ yoshimi
SSE2 detected
Error, failed to start jack midi thread: 1
So sad, failed to start MusicIO
Yoshimi stages a strategic retreat :-(
Floating point exception
diego@diego-laptop:~$
diego@diego-laptop:~$
Any idea on this error?
Thank you very much in advance,
BR
Diego
2010/1/13 David Adler <david.jo.adler(a)gmail.com>
On Tue, Jan 12, 2010 at 8:26 PM, cal wrote:
The main change in 0.051 is to the recorder start
logic, which sort of
goes like -
- Select your wav file, and the recorder becomes
armed.
- When armed, recording starts with the first note-on event, or a click
on
the Record button.
- When armed, a click on the Stop button disarms the recorder.
- When recording, a click on the Stop button stops the recorder, leaving
it
armed.
<http://sourceforge.net/projects/yoshimi/files/>
The sourceforge link seems to be outdated, still on version 0.047.1.
No problen, good old
http://www.graggrag.com/?q=node/19
is up to date.
A build error:
/home/abs/yoshimi/src/yoshimi-0.051/src/MasterUI.h:28:24: error:
fltk/Color.h: No such file or directory
[...]
Aborting...
installing fltk2 resolved it.
Next, on startup:
$ yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/user/.zynaddsubfxXML.cfg could not be loaded or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
I found a .zynaddsubfxXML.cfg online from trinity. With that it
worked, though with an unusual layout.
I unsuccessfully looked for other .cfg files to use (using google
and searching zynadd 2.4.0/zynadd git). I'd love to have
one that gives the old layout.
The whole story is the same with yoshimi 0.052-pre1
Thanks for zyn, thanks again for yoshimi,
best,
d
Bon apetit.
thanks, tasty miso soup on my table :)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
7:32 a.m.
On Wed, Jan 13, 2010 at 4:47 AM, David Adler wrote:
[snip]
Next, on startup:
$ yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/user/.zynaddsubfxXML.cfg could not be loaded or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
I found a .zynaddsubfxXML.cfg online from trinity. With that it
worked, though with an unusual layout.
I unsuccessfully looked for other .cfg files to use (using google
and searching zynadd 2.4.0/zynadd git). I'd love to have
one that gives the old layout.
I have found such a .zynaddsubfxXML.cfg on my other machine, no clue
yet what created it/where it comes from. It's about as old as the
installation.
yoshimi 0.051 requires it, 0.047.1 and zynaddsubfx run without it with
the usual default layout.
greetings,
d
12:02 p.m.
Sorry folks. As seems to be my custom whenever I put out an update, 0.051
is broken, hence it's removal from SF (leaving it on graggrag was an oversight).
David Adler wrote:
[ ... ]
/home/abs/yoshimi/src/yoshimi-0.051/src/MasterUI.h:28:24: error:
fltk/Color.h: No such file or directory
Sloppy work on my part, the include needs to be deleted.
[ ... ]
$ yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/user/.zynaddsubfxXML.cfg could not be loaded or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
As someone else mentions, this one has come up before, but I haven't figured it out
yet (clearly).
The fabulous new recorder start logic in 0.051 is also quite broken. It works fine with
jack audio + jack midi and alsa audio + alsa midi, but not with jack audio + alsa midi or
alsa audio + jack midi.
Thanks for zyn, thanks again for yoshimi,
Given the crap I regularly dish out, you people are incredibly patient and tolerant, very
much appreciated. Health since Christmas has been ordinary, and so has the code I've
produced :-(. I think I'm close to the point where I have to give this away, but
meanwhile I'll fix it as soon as I can.
cheers, Cal
12:47 p.m.
Excerpts from cal's message of Wed Jan 13 17:02:43 +0100 2010:
Sorry folks. As seems to be my custom whenever I put
out an update, 0.051
is broken, hence it's removal from SF (leaving it on graggrag was an oversight).
David Adler wrote:
yep 0.051 doesn't even start after a clean install since it seems to
miss a conf file:
yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/murks/.zynaddsubfxXML.cfg could not be loaded
or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
Segmentation fault
Thanks for all the effort you put into this Cal.
I wish you best health.
Regards,
Philipp
[ ... ]
/home/abs/yoshimi/src/yoshimi-0.051/src/MasterUI.h:28:24: error:
fltk/Color.h: No such file or directory
Sloppy work on my part, the include needs to be deleted.
[ ... ]
$ yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/user/.zynaddsubfxXML.cfg could not be loaded or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
As someone else mentions, this one has come up before, but I haven't figured it
out yet (clearly).
The fabulous new recorder start logic in 0.051 is also quite broken. It works
fine with jack audio + jack midi and alsa audio + alsa midi, but not with jack
audio + alsa midi or alsa audio + jack midi.
Thanks for zyn, thanks again for yoshimi,
Given the crap I regularly dish out, you people are incredibly patient and
tolerant, very much appreciated. Health since Christmas has been ordinary, and
so has the code I've produced :-(. I think I'm close to the point where I have
to give this away, but meanwhile I'll fix it as soon as I can.
cheers, Cal
15 Jan
15 Jan
8:26 a.m.
Hello all,
Same problem over here, after installing fltk2 the fltk/Color.h
problem was solved and it installed correctly.
Now on the startup stage I'm getting this error, which seems to be
related to jack or midi setup:
Error, failed to start jack midi thread: 1
So sad, failed to start MusicIO
***** here's the entire output:
diego@diego-laptop:~$ /usr/bin/jackd -dalsa -dhw:0,0 -r44100 -p1024 -n2 &
[1] 8456
diego@diego-laptop:~$ no message buffer overruns
jackd 0.116.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
SSE2 detected
apparent rate = 44100
creating alsa driver ... hw:0,0|hw:0,0|1024|2|44100|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
diego@diego-laptop:~$
diego@diego-laptop:~$
diego@diego-laptop:~$ yoshimi
SSE2 detected
Error, failed to start jack midi thread: 1
So sad, failed to start MusicIO
Yoshimi stages a strategic retreat :-(
Floating point exception
diego@diego-laptop:~$
diego@diego-laptop:~$
Any idea on this error?
Thank you very much in advance,
BR
Diego
2010/1/13 Philipp Überbacher <hollunder(a)lavabit.com>om>:
Excerpts from cal's message of Wed Jan 13 17:02:43
+0100 2010:
Sorry folks. As seems to be my custom whenever I
put out an update, 0.051
is broken, hence it's removal from SF (leaving it on graggrag was an oversight).
David Adler wrote:
yep 0.051 doesn't even start after a clean install since it seems to
miss a conf file:
yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/murks/.zynaddsubfxXML.cfg could not be loaded
or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
Segmentation fault
Thanks for all the effort you put into this Cal.
I wish you best health.
Regards,
Philipp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
[ ... ]
/home/abs/yoshimi/src/yoshimi-0.051/src/MasterUI.h:28:24: error:
fltk/Color.h: No such file or directory
Sloppy work on my part, the include needs to be deleted.
[ ... ]
$ yoshimi
gzopen failed, errno 2, No such file or directory
Error, xml file /home/user/.zynaddsubfxXML.cfg could not be loaded or
uncompressed
BUG!: XMLwrapper::peek() - empty parentstack
BUG!: XMLwrapper::peek() - empty parentstack
As someone else mentions, this one has come up before, but I haven't figured it
out yet (clearly).
The fabulous new recorder start logic in 0.051 is also quite broken. It works
fine with jack audio + jack midi and alsa audio + alsa midi, but not with jack
audio + alsa midi or alsa audio + jack midi.
Thanks for zyn, thanks again for yoshimi,
Given the crap I regularly dish out, you people are incredibly patient and
tolerant, very much appreciated. Health since Christmas has been ordinary, and
so has the code I've produced :-(. I think I'm close to the point where I have
to give this away, but meanwhile I'll fix it as soon as I can.
cheers, Cal
10:10 a.m.
Diego Simak wrote:
[ ... ]
Error, failed to start jack midi thread: 1
That's coming from a pthread_create, which needs to set SCHED_FIFO on the midi thread.
I don't see any mention of realtime in your jack startup. Do you have your realtime
settings organized in /etc/security/limits.conf, /etc/security/limits.d and all that
stuff?
cheers.
10:25 a.m.
Hi Cal,
No, I don't have realtime setting in jack since with this it cannot be
executed...
I will check how to configure realtime settings and I'll let you know.
Thank you very much,
Diego
2010/1/15 cal <cal(a)graggrag.com>om>:
Diego Simak wrote:
[ ... ]
Error, failed to start jack midi thread: 1
That's coming from a pthread_create, which needs to set SCHED_FIFO on the midi
thread. I don't see any mention of realtime in your jack startup. Do you have your
realtime settings organized in /etc/security/limits.conf, /etc/security/limits.d and all
that stuff?
cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:13 a.m.
Diego Simak wrote:
Hi Cal,
No, I don't have realtime setting in jack since with this it cannot be
executed...
I will check how to configure realtime settings and I'll let you know.
Getting the realtime stuff working for the first time can be a pain, but
you're going to need it to do anything interesting with jack.
cheers.
noon
Thanks Cal, I just have compiled kernel 2.6.31.6-rt19 with preemption
patch on it
I will go through it from here.... thanks for your encouragement words ;-)
BR
Diego
2010/1/15 cal <cal(a)graggrag.com>om>:
Diego Simak wrote:
Hi Cal,
No, I don't have realtime setting in jack since with this it cannot be
executed...
I will check how to configure realtime settings and I'll let you know.
Getting the realtime stuff working for the first time can be a pain, but
you're going to need it to do anything interesting with jack.
cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
1:29 p.m.
Hi, I just added these 2 lines to the /etc/security/limits.conf file
and now I'm able to run jack with RT option.
@audio - rtprio 99
@audio - memlock unlimited
I'm able to execute yoshimi !! but it doesn't register in jack
observing also this message during the execution:
diego@diego-laptop:~$ yoshimi
Error, alsa audio: alsa audio mmap not possible: Invalid argument
ADsynth Oscilsize: 1024
Sample Rate: 44100
Sound Buffer Size: 256
Internal latency: 5.80499 ms
The problem now is that I have no sound.... probable maybe after
compiling the 2.6.31.6-rt19 RT kernel....I will look into it now.
Thank you very much for your help,
BR
Diego
2010/1/15 Diego Simak <diego.simak(a)gmail.com>om>:
Thanks Cal, I just have compiled kernel 2.6.31.6-rt19
with preemption
patch on it
I will go through it from here.... thanks for your encouragement words ;-)
BR
Diego
2010/1/15 cal <cal(a)graggrag.com>om>:
Diego Simak wrote:
Hi Cal,
No, I don't have realtime setting in jack since with this it cannot be
executed...
I will check how to configure realtime settings and I'll let you know.
Getting the realtime stuff working for the first time can be a pain, but
you're going to need it to do anything interesting with jack.
cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:01 p.m.
It was my problem....I had compiled yoshimi with DEFAULT_AUDIO as ALSA
instead of JACK.... after recompiling I'm able to hear sound through
JACK !!!!
Thank you very very much!!!!!
Best regards,
Diego
2010/1/15 Diego Simak <diego.simak(a)gmail.com>om>:
Hi, I just added these 2 lines to the
/etc/security/limits.conf file
and now I'm able to run jack with RT option.
@audio - rtprio 99
@audio - memlock unlimited
I'm able to execute yoshimi !! but it doesn't register in jack
observing also this message during the execution:
diego@diego-laptop:~$ yoshimi
Error, alsa audio: alsa audio mmap not possible: Invalid argument
ADsynth Oscilsize: 1024
Sample Rate: 44100
Sound Buffer Size: 256
Internal latency: 5.80499 ms
The problem now is that I have no sound.... probable maybe after
compiling the 2.6.31.6-rt19 RT kernel....I will look into it now.
Thank you very much for your help,
BR
Diego
2010/1/15 Diego Simak <diego.simak(a)gmail.com>om>:
Thanks Cal, I just have compiled kernel
2.6.31.6-rt19 with preemption
patch on it
I will go through it from here.... thanks for your encouragement words ;-)
BR
Diego
2010/1/15 cal <cal(a)graggrag.com>om>:
Diego Simak wrote:
Hi Cal,
No, I don't have realtime setting in jack since with this it cannot be
executed...
I will check how to configure realtime settings and I'll let you know.
Getting the realtime stuff working for the first time can be a pain, but
you're going to need it to do anything interesting with jack.
cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
16 Jan
16 Jan
8:10 a.m.
cal wrote:
The main change in 0.051 is to the recorder start
logic, which sort of goes like -
- Select your wav file, and the recorder becomes armed.
- When armed, recording starts with the first note-on event, or a click on
the Record button.
- When armed, a click on the Stop button disarms the recorder.
- When recording, a click on the Stop button stops the recorder, leaving it
armed.
<http://sourceforge.net/projects/yoshimi/files/>
Bon apetit.
Yoshimi is not usable for me as an instrument because of the many xruns.
\r
8:18 a.m.
On Sat, 16 Jan 2010 13:07:23 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
cal wrote:
I'm astonished that you have this problem. I have found it to be far
less prone to these than the zyn 2.4 source.
What is your setup?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
The main change in 0.051 is to the recorder start
logic, which sort of goes like -
- Select your wav file, and the recorder becomes armed.
- When armed, recording starts with the first note-on event, or a click on
the Record button.
- When armed, a click on the Stop button disarms the recorder.
- When recording, a click on the Stop button stops the recorder, leaving it
armed.
<http://sourceforge.net/projects/yoshimi/files/>
Bon apetit.
Yoshimi is not usable for me as an instrument because of the many xruns.
\r
8:37 a.m.
Folderol wrote:
On Sat, 16 Jan 2010 13:07:23 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
What is less prone? Having regular xruns but less then it was before? Do
you get xruns? More when using certain instruments? Or playing chords?
Especially when I switch instruments and play chords, is quite simple
sometimes to reach to 1000 xruns in a few minuts... I think for an
instrument you should have almost none xruns in an hour and strive to
get none...
cal wrote:
I'm astonished that you have this problem. I have found it to be far
less prone to these than the zyn 2.4 source.
The main change in 0.051 is to the recorder start
logic, which sort of goes like -
- Select your wav file, and the recorder becomes armed.
- When armed, recording starts with the first note-on event, or a click on
the Record button.
- When armed, a click on the Stop button disarms the recorder.
- When recording, a click on the Stop button stops the recorder, leaving it
armed.
<http://sourceforge.net/projects/yoshimi/files/>
Bon apetit.
Yoshimi is not usable for me as an instrument because of the many xruns.
\r
What is your setup?
Debian testing, Jack2, RT kernel :
Linux debian 2.6.31.6-rt19-1-686 #1 SMP PREEMPT RT Thu Nov 12 13:22:20
UTC 2009 i686 GNU/Linux
@audio - rtprio 99
@audio - memlock unlimited
I'm using an maudio keystation usb midi keyboard
I think I have a pretty proper configured system... No problems with
other apps.
\r
9:43 a.m.
On Sat, 16 Jan 2010 13:34:45 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
Folderol wrote:
With yoshimi I get no xruns at all while playing 3-4 note chords with
the left hand plus a melody line with the right hand. This is true even
with my most complex patches. With the most recent versions, I only see
xruns while changing instrument patch at the same time as actually
playing notes (which is a pretty daft thing to do).
On Sat, 16 Jan 2010 13:07:23 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
What is less prone? Having regular xruns but less then it was before? Do
you get xruns? More when using certain instruments? Or playing chords? cal wrote:
I'm astonished that you have this problem. I have found it to be far
less prone to these than the zyn 2.4 source.
The main change in 0.051 is to the recorder start
logic, which sort of goes like -
- Select your wav file, and the recorder becomes armed.
- When armed, recording starts with the first note-on event, or a click on
the Record button.
- When armed, a click on the Stop button disarms the recorder.
- When recording, a click on the Stop button stops the recorder, leaving it
armed.
<http://sourceforge.net/projects/yoshimi/files/>
Bon apetit.
Yoshimi is not usable for me as an instrument because of the many xruns.
\r
Especially when I switch instruments and play chords,
is quite simple
sometimes to reach to 1000 xruns in a few minuts... I think for an
instrument you should have almost none xruns in an hour and strive to
get none...
This is far more recent that what I'm working with (2.6.29) - I know
there have been problems with some rt kernels but I don't know which
ones. Also I tend to work with targeted music distros, such as 64studio,
where some extra optimisations are done.
What is your setup?
Debian testing, Jack2, RT kernel :
Linux debian 2.6.31.6-rt19-1-686 #1 SMP PREEMPT RT Thu Nov 12 13:22:20
UTC 2009 i686 GNU/Linux @audio - rtprio 99
@audio - memlock unlimited
This looks normal, but I don't see a 'nice' setting. Mine is -10
I'm using an maudio keystation usb midi keyboard
I don't know this particular keyboard but I have heard that some USB
ones have problems. I think this actually a mobo problem where there
are shared interrupts, but I'm far from certain about that.
I think I have a pretty proper configured system... No
problems with
other apps.
Are the other apps synths or sample players? and do you drive them
directly from the keyboard?
P.S.
Just done some test and I can create xruns if I use my most processor
intensive patches 'hyper matrix' and 'master synth low', but to do
this I have to play quite fast fully chorded, which is really not what
these patches are intended for. Both of these are four instrument voice
'kits' with long release times and significant extra effects.
Are you running similar heavy-duty voices?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
9:57 a.m.
Folderol wrote:
On Sat, 16 Jan 2010 13:34:45 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
Mhh it sounds like your yoshimi with your setup is performing much
better then mine.
Maybe it's the hardware? I've just an simple P4 (2.25) , 1gb ram, maudio
audiophile card.
What Jack settings do you use?
\r
Folderol wrote:
With yoshimi I get no xruns at all while playing 3-4 note chords with
the left hand plus a melody line with the right hand. This is true even
with my most complex patches. With the most recent versions, I only see
xruns while changing instrument patch at the same time as actually
playing notes (which is a pretty daft thing to do).
On Sat, 16 Jan 2010 13:07:23 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
What is less prone? Having regular xruns but less then it was before? Do
you get xruns? More when using certain instruments? Or playing chords?
cal wrote:
> The main change in 0.051 is to the recorder start logic, which sort of goes like -
> - Select your wav file, and the recorder becomes armed.
> - When armed, recording starts with the first note-on event, or a click on
> the Record button.
> - When armed, a click on the Stop button disarms the recorder.
> - When recording, a click on the Stop button stops the recorder, leaving it
> armed.
>
> <http://sourceforge.net/projects/yoshimi/files/>
>
> Bon apetit.
>
>
>
Yoshimi is not usable for me as an instrument because of the many xruns.
\r
I'm astonished that you have this problem. I have found it to be far
less prone to these than the zyn 2.4 source.
Especially when I switch instruments and play
chords, is quite simple
sometimes to reach to 1000 xruns in a few minuts... I think for an
instrument you should have almost none xruns in an hour and strive to
get none...
This is far more recent that what I'm working with (2.6.29) - I know
there have been problems with some rt kernels but I don't know which
ones. Also I tend to work with targeted music distros, such as 64studio,
where some extra optimisations are done.
What is your setup?
Debian testing, Jack2, RT kernel :
Linux debian 2.6.31.6-rt19-1-686 #1 SMP PREEMPT RT Thu Nov 12 13:22:20
UTC 2009 i686 GNU/Linux
@audio - rtprio 99
@audio - memlock unlimited
This looks normal, but I don't see a 'nice' setting. Mine is -10
I'm using an maudio keystation usb midi
keyboard
I don't know this particular keyboard but I have heard that some USB
ones have problems. I think this actually a mobo problem where there
are shared interrupts, but I'm far from certain about that.
I think I have a pretty proper configured
system... No problems with
other apps.
Are the other apps synths or sample players? and do you drive them
directly from the keyboard?
P.S.
Just done some test and I can create xruns if I use my most processor
intensive patches 'hyper matrix' and 'master synth low', but to do
this I have to play quite fast fully chorded, which is really not what
these patches are intended for. Both of these are four instrument voice
'kits' with long release times and significant extra effects.
Are you running similar heavy-duty voices?
6:08 p.m.
On Sat, 16 Jan 2010 14:54:50 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
Folderol wrote:
That might be part of it. I run a dual core 64bit machine and have 4G
memory. I also use it ONLY for music. Internet and office stuff are
all done on a cheap general purpose machine.
On Sat, 16 Jan 2010 13:34:45 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
Mhh it sounds like your yoshimi with your setup is performing much
better then mine.
Maybe it's the hardware? I've just an simple P4 (2.25) , 1gb ram, maudio
audiophile card. Folderol wrote:
With yoshimi I get no xruns at all while playing 3-4 note chords with
the left hand plus a melody line with the right hand. This is true even
with my most complex patches. With the most recent versions, I only see
xruns while changing instrument patch at the same time as actually
playing notes (which is a pretty daft thing to do).
On Sat, 16 Jan 2010 13:07:23 +0100
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
> cal wrote:
>
>
>> The main change in 0.051 is to the recorder start logic, which sort of goes like
-
>> - Select your wav file, and the recorder becomes armed.
>> - When armed, recording starts with the first note-on event, or a click on
>> the Record button.
>> - When armed, a click on the Stop button disarms the recorder.
>> - When recording, a click on the Stop button stops the recorder, leaving it
>> armed.
>>
>> <http://sourceforge.net/projects/yoshimi/files/>
>>
>> Bon apetit.
>>
>>
>>
> Yoshimi is not usable for me as an instrument because of the many xruns.
>
>
> \r
>
>
I'm astonished that you have this problem. I have found it to be far
less prone to these than the zyn 2.4 source.
What is less prone? Having regular xruns but less then it was before? Do
you get xruns? More when using certain instruments? Or playing chords?
Especially when I switch instruments and play
chords, is quite simple
sometimes to reach to 1000 xruns in a few minuts... I think for an
instrument you should have almost none xruns in an hour and strive to
get none...
This is far more recent that what I'm working with (2.6.29) - I know
there have been problems with some rt kernels but I don't know which
ones. Also I tend to work with targeted music distros, such as 64studio,
where some extra optimisations are done.
What is your setup?
Debian testing, Jack2, RT kernel :
Linux debian 2.6.31.6-rt19-1-686 #1 SMP PREEMPT RT Thu Nov 12 13:22:20
UTC 2009 i686 GNU/Linux
@audio - rtprio 99
@audio - memlock unlimited
This looks normal, but I don't see a 'nice' setting. Mine is -10
I'm using an maudio keystation usb midi
keyboard
I don't know this particular keyboard but I have heard that some USB
ones have problems. I think this actually a mobo problem where there
are shared interrupts, but I'm far from certain about that.
I think I have a pretty proper configured
system... No problems with
other apps.
Are the other apps synths or sample players? and do you drive them
directly from the keyboard?
P.S.
Just done some test and I can create xruns if I use my most processor
intensive patches 'hyper matrix' and 'master synth low', but to do
this I have to play quite fast fully chorded, which is really not what
these patches are intended for. Both of these are four instrument voice
'kits' with long release times and significant extra effects.
Are you running similar heavy-duty voices?
What Jack settings do you use?
Mostly the default settings. For just Rosegarden and Zyn. I set 64
frames / period which gives a latency of 2.9mS, if I've got a lot of
other stuff running as well, or if I'm using the most complex patches I
go up to 128 frames / period, which is 5.8mS.
On very rare occasions I have to go up to 11.6mS - this is what I had
to have most of the time with Zyn 2.2.1, although then it was zombies
that were the main problem rather than xruns :(
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
17 Jan
17 Jan
9:40 a.m.
Folderol wrote:
That might be part of it. I run a dual core 64bit
machine and have 4G
memory. I also use it ONLY for music. Internet and office stuff are
all done on a cheap general purpose machine.
I just tested yoshimi on Ubuntu 9.10, wow that performs 1000x better
then on my Debian testing box. This is good and bad news...
How to find out what is wrong on my system? Other apps like Ardour and
Hydrogen seems to work well...
I got these xrun messages:
Jack reports xrun
Jack reports error: JackActivationCount::Signal value = 0 ref = 3
\r
What Jack settings do you use?
Mostly the default settings. For just Rosegarden and Zyn. I set 64
frames / period which gives a latency of 2.9mS, if I've got a lot of
other stuff running as well, or if I'm using the most complex patches I
go up to 128 frames / period, which is 5.8mS.
On very rare occasions I have to go up to 11.6mS - this is what I had
to have most of the time with Zyn 2.2.1, although then it was zombies
that were the main problem rather than xruns :(
10:08 a.m.
rosea grammostola wrote:
[ ... ]
I just tested yoshimi on Ubuntu 9.10, wow that performs 1000x better
then on my Debian testing box.
excellent, that's how it's supposed to be.
... This is good and bad news...
How to find out what is wrong on my system? Other apps like Ardour and
Hydrogen seems to work well...
Dunno. I'm on an athlon x2 5600 x86_64 debian testing, and I don't get
significant xrun issues until things get to around 60% cpu.
I got these xrun messages:
Jack reports xrun
Jack reports error: JackActivationCount::Signal value = 0 ref = 3
jackdmp/jack2 right? I get lots of those too. So far I haven't found (or
even looked hard) for what they mean. I've got things to the point where
I don't actually hear anything when they're happening, so I can dismiss
them as mostly harmless. Maybe I'm imagining that, I seem to be doing
lots of imaginary things with yoshimi lately.
This afternoon and evening I've been doing some semi-serious testing,
and I'm getting segfaults and all manner of untidiness. My advice for
now is to stand well back while I work on it. I had a report today
that 0.036 was working well :-).
cheers, Cal
10:20 a.m.
cal wrote:
rosea grammostola wrote:
Situation is now, that I don't get xruns when I use zynaddsubfx, latest
compiled from source, when I use the vkeybd of zynadd. I get regular
xruns when I use my maudio keystation usb keyboard though...
For latest yoshimi, it doesn't matter whether which keybd I use. Xruns
all over the place...
\r
[ ... ]
I just tested yoshimi on Ubuntu 9.10, wow that performs 1000x better
then on my Debian testing box.
excellent, that's how it's supposed to be.
... This is good and bad news...
How to find out what is wrong on my system? Other apps like Ardour and
Hydrogen seems to work well...
Dunno. I'm on an athlon x2 5600 x86_64 debian testing, and I don't get
significant xrun issues until things get to around 60% cpu.
10:30 a.m.
rosea grammostola wrote:
cal wrote:
On Ubuntu 9.10, no xruns, no matter which keyboard I use....
If I recall well, there where some ulimit issues on my debian system...
But they where vague...
On Debian testing:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
rosea grammostola wrote:
Situation is now, that I don't get xruns when I use zynaddsubfx,
latest compiled from source, when I use the vkeybd of zynadd. I get
regular xruns when I use my maudio keystation usb keyboard though...
For latest yoshimi, it doesn't matter whether which keybd I use. Xruns
all over the place...
\r
[ ... ]
I just tested yoshimi on Ubuntu 9.10, wow that performs 1000x better
then on my Debian testing box.
excellent, that's how it's supposed to be.
... This is good and bad news...
How to find out what is wrong on my system? Other apps like Ardour
and Hydrogen seems to work well...
Dunno. I'm on an athlon x2 5600 x86_64 debian testing, and I don't get
significant xrun issues until things get to around 60% cpu.
10:43 a.m.
rosea grammostola wrote:
[ ... ]
On Ubuntu 9.10, no xruns, no matter which keyboard I use....
If I recall well, there where some ulimit issues on my debian system...
But they where vague...
On Debian testing:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Mine's exactly the same. I can't see it being ulimit though. My prime suspect
would be rtprio rights, next would be the kernel.
A left fieldish memory prompts me to ask, is it the same window manager on
ubuntu as the debian testing?
cheers.
12:10 p.m.
cal wrote:
rosea grammostola wrote:
How do I troubleshoot that? How can I find out if it's rtprio?
I don't think the kernel itself is the problem, I tried different ones.
[ ... ]
On Ubuntu 9.10, no xruns, no matter which keyboard I use....
If I recall well, there where some ulimit issues on my debian system...
But they where vague...
On Debian testing:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Mine's exactly the same. I can't see it being ulimit though. My prime suspect
would be rtprio rights, next would be the kernel.
A left fieldish memory prompts me to ask, is it the
same window manager on
ubuntu as the debian testing?
I have kde4 installed and use apps from it, but I use
fluxbox as wm.
In Ubuntu it is gnome
\r
12:14 p.m.
rosea grammostola wrote:
cal wrote:
Another problem which I may have is a direct rendering problem with my
video card driver, matrox, mga... dunno if that can be related to an
audio issue....
(EE) MGA(0): [drm] Failed to initialize DMA! (-2)
(II) MGA(0): [drm] removed 1 reserved context for kernel
(II) MGA(0): [drm] unmapping 8192 bytes of SAREA 0xf7c2e000 at 0xb780d000
(II) MGA(0): [drm] Closed DRM master.
(WW) MGA(0): Direct rendering disabled
rosea grammostola wrote:
How do I troubleshoot that? How can I find out if it's rtprio?
I don't think the kernel itself is the problem, I tried different ones.
[ ... ]
On Ubuntu 9.10, no xruns, no matter which keyboard I use....
If I recall well, there where some ulimit issues on my debian
system... But they where vague...
On Debian testing:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Mine's exactly the same. I can't see it being ulimit though. My prime
suspect
would be rtprio rights, next would be the kernel.
A left fieldish memory prompts me to ask, is it
the same window
manager on
ubuntu as the debian testing?
I have kde4 installed and use apps from it, but I
use fluxbox as wm.
In Ubuntu it is gnome
\r
1:01 p.m.
New subject: yoshimi stands still
rosea grammostola wrote:
[ ... ]
>> suspect
>> would be rtprio rights, next would be the kernel.
>>
> How do I troubleshoot that? How can I find out if it's rtprio?
Do you start jack with -R, and do you see a line like
"JACK server starting in realtime mode with priority 80"
in the blurb jack spits out at startup?
If not, then there's the problem. Otherwise, it a puzzle.
> I don't think the kernel itself is the
problem, I tried different ones.
I'd go along with that.
>> A left fieldish memory prompts me to ask, is
it the same window
>> manager on
>> ubuntu as the debian testing?
> I have kde4 installed and use apps from it, but I use fluxbox as wm.
>
> In Ubuntu it is gnome
Nah, I think what I had in mind is irrelevant.
Another problem which I may have is a direct rendering
problem with my
video card driver, matrox, mga... dunno if that can be related to an
audio issue....
(EE) MGA(0): [drm] Failed to initialize DMA! (-2)
(II) MGA(0): [drm] removed 1 reserved context for kernel
(II) MGA(0): [drm] unmapping 8192 bytes of SAREA 0xf7c2e000 at 0xb780d000
(II) MGA(0): [drm] Closed DRM master.
(WW) MGA(0): Direct rendering disabled
wow, it's been a while since my mga even saw colour. All I can think of is the
kernel module -
Device Drivers --->
Graphics support --->
Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --->
Matrox g200/g400
18 Jan
18 Jan
6:33 a.m.
New subject: yoshimi stands still
cal wrote:
rosea grammostola wrote:
Then it is a
puzzle...
\r
[ ... ]
>> suspect
>> would be rtprio rights, next would be the kernel.
>>
>>
> How do I troubleshoot that? How can I find out if it's rtprio?
>
Do you start jack with -R, and do you see a line like
"JACK server starting in realtime mode with priority 80"
in the blurb jack spits out at startup?
If not, then there's the problem. Otherwise, it a puzzle. 
18 Jan
18 Jan
6:33 a.m.
Jonathan E. Brickman wrote:
Thanks, tried it, didn't improve
\r
A left
fieldish memory prompts me to ask, is it the same window manager on
ubuntu as the debian testing?
cheers.
What about Jack version, and Jack sync mode in jack2? Everything
improved tremendously for me in sync mode.
17 Jan
17 Jan
10:37 a.m.
New subject: yoshimi creeps... (backwards)
rosea grammostola wrote:
[ ... ]
Situation is now, that I don't get xruns when I use zynaddsubfx, latest
compiled from source, when I use the vkeybd of zynadd. I get regular
xruns when I use my maudio keystation usb keyboard though...
which suggests that the zyn jack midi still isn't quite there.
For latest yoshimi, it doesn't matter whether
which keybd I use. Xruns
all over the place...
In current yoshimi there's been some reorganising, and there's few things
still needing settling. It's not a difficult choice, go with Zyn or an
earlier version of yoshimi. I think all I've ever promised is a
development snapshot, but I really do want to settle this thing down
and move on.
cheers, Cal
9:45 a.m.
Jonathan E. Brickman wrote:
Ardour, hydrogen, non-sequencer,
jack-mixer, qsynth, linuxsampler for
instance...
You start to think it is something specific to yoshimi/zynaddsubfx...
I'll do some more testing with other apps.
\r
I think I have
a pretty proper configured system... No problems with
other apps.
What other apps are you using?
19 Jan
19 Jan
2 a.m.
rosea grammostola wrote:
The way zyn works pushes the bounds of good sense in terms of actually
generating it's sound in realtime, but you gradually learn the limitations
and how to have fun within those limitations. The main difference with
yoshi is the audio/midi drivers plus some refinement (nothing radical)
to the sound generation processing cycle. So far, yoshimi does both the
drivers and the generation cycle better than original zyn, but I think
we'd all like zynaddsubfx to catch up and get it right at last. Frankly
I can't see that happening any time soon, but I am a registered cynic in
that area.
What other apps are you using?
Ardour,
hydrogen, non-sequencer, jack-mixer, qsynth, linuxsampler for
instance...
You start to think it is something specific to yoshimi/zynaddsubfx... I'll do some more testing with other apps.
And I think I can predict the results. If you're running a whole bunch of
other apps on the same system at the same time as zyn/yoshi, then the cpu
grunt available to zyn/yoshi is going to reduce accordingly, and so is the
level of sound complexity you'll be able to achieve in realtime. Currently,
yoshimi sets the priority of the midi and audio threads to 50 (or 55, can't
remember), and they're competing for cpu with everything else you've got
running SCHED_FIFO.
If you really, really, really want the sounds zyn/yoshi can produce, then
you learn to accommodate its demands and limitations in terms of resource
availability. If you can't accommodate those requirements, then you really
need to use a different synth.
cheers.
16 Jan
16 Jan
10:53 a.m.
rosea grammostola wrote:
[ ... ]
Yoshimi is not usable for me as an
instrument because of the many xruns.
If you're using 0.051, then yes, what you're describing is possible. There's
a little story that might help explain that at
https://sourceforge.net/mailarchive/forum.php?thread_name=4B517CD1.4090205%…
I think Will was smart enough to not use 0.051, and I think his description
fits the earlier versions and the general experience of other users.
I've actually put up an 0.053-pre1 tarball on graggrag.com, and I'm starting
to get some confidence in it.
cheers, Cal
6:13 p.m.
On Sun, 17 Jan 2010 01:52:56 +1100
cal <cal(a)graggrag.com> wrote:
rosea grammostola wrote:
Good news and bad news :?
Recording now works very nicely :D
0.053 is somehow corrupting the .yoshimiXML.cfg file. It fails to read
it (using the default settings), then if I try an earlier version that
can no longer read it either :(
I solved the problem partially by copying across the Zyn. one then
making it read-only, so the older versions of yoshi are safe, but the
latest one still can't read the file.
.xmz parameter files seem to load without problems.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
[ ... ]
Yoshimi is not usable for me as an
instrument because of the many xruns.
If you're using 0.051, then yes, what you're describing is possible. There's
a little story that might help explain that at
https://sourceforge.net/mailarchive/forum.php?thread_name=4B517CD1.4090205%…
I think Will was smart enough to not use 0.051, and I think his description
fits the earlier versions and the general experience of other users.
I've actually put up an 0.053-pre1 tarball on graggrag.com, and I'm starting
to get some confidence in it.
cheers, Cal
7:54 p.m.
Folderol wrote:
[ ... ]
Good news and bad news :?
Recording now works very nicely :D
I am pleased!
0.053 is somehow corrupting the .yoshimiXML.cfg file.
It fails to read
it (using the default settings), then if I try an earlier version that
can no longer read it either :(
I solved the problem partially by copying across the Zyn. one then
making it read-only, so the older versions of yoshi are safe, but the
latest one still can't read the file.
mutter, mutter ... disappointed, but not entirely surprised. Any chance you
could send me a copy of the problematic .cfg file? There's a few mysteries
(to me at least) on what to do with the redundant (in yoshi) zyn settings,
so if I can look at what's causing you grief it might help. An unattractive
workaround might be to simply delete .yoshimiXML.cfg. Next time you run
yoshi it'll start with basic defaults, and from there perhaps it might
behave sanely given that it'll write out the settings on exit. You can also
explicitly save them from the Settings panel. That would mean you'd then
have to go through Settings and set up all your preferences again, so I
think I'd like to take a look at your .cfg file before I'd recommend that.
.xmz parameter files seem to load without problems.
Just as well too!
cheers, Cal
17 Jan
17 Jan
2:29 a.m.
cal wrote:
An unattractive
workaround might be to simply delete .yoshimiXML.cfg. Next time you run
yoshi it'll start with basic defaults, and from there perhaps it might
behave sanely given that it'll write out the settings on exit. You can also
explicitly save them from the Settings panel.
I have same problem too, and I started from no cfg. I'm basically just
trying to set the bank root dir, works just after setting it, but it's
forgotten on next application start.
This is with 0.053-pre2.
--
Atte
http://atte.dk http://modlys.dk
5517
days inactive
5524
days old
linux-audio-user@lists.linuxaudio.org
39 comments
8 participants
participants (8)
-
Atte André Jensen -
cal -
David Adler -
Diego Simak -
Folderol -
Jonathan E. Brickman -
Philipp Überbacher -
rosea grammostola