20 Jan
2010
20 Jan
'10
1:39 a.m.
For better or worse, there's an 0.053-pre3 on
<http://www.graggrag.com/?q=yoshimi>.
The settings corruption seems fixed, and some stray chaos from the recorder
reorg seems to be under control.
In the vague hope that it might help when I stuff things up, I've put up an
0.053-pre2-0.053-pre3.diff as well.
cheers, Cal
20 Jan
20 Jan
2:22 a.m.
cal wrote:
The settings corruption seems fixed, and some stray
chaos from the recorder
reorg seems to be under control.
A quick test indeed shows that my "yoshimi not remembering my bank
dir"-problem is gone. Thanks!
--
Atte
http://atte.dk http://modlys.dk
3:21 a.m.
cal wrote:
For better or worse, there's an 0.053-pre3 on
<http://www.graggrag.com/?q=yoshimi>.
The settings corruption seems fixed, and some stray chaos from the recorder
reorg seems to be under control.
Well, for what it's worth, here on a non-RT kernel but with RTPRIO set
properly in limits.conf, using jackdmp 1.9.2:
david@eurolap:~$ yoshimi
Error, failed to start Alsa midi thread: 1
Error - bail out of AlsaEngine::Start()
Error, failed to cancel Alsa midi thread
So sad, failed to start MusicIO
Yoshimi stages a strategic retreat :-(
david@eurolap:~$ yoshimi -J -j
Error, failed to start jack midi thread: 1
Error, failed to cancel Jack midi thread
So sad, failed to start MusicIO
Yoshimi stages a strategic retreat :-(
david@eurolap:~$ yoshimi -J -a
Error, failed to start Alsa midi thread: 1
Error - bail out of AlsaEngine::Start()
Error, failed to cancel Alsa midi thread
So sad, failed to start MusicIO
Yoshimi stages a strategic retreat :-(
yoshimi: ../../src/xcb_lock.c:32: _XCBUnlockDisplay: Assertion
`dpy->xcb->partial_request == 0' failed.
Aborted
david@eurolap:~$ yoshimi -A -a
ALSA lib pcm_dmix.c:996:(snd_pcm_dmix_open) unable to open slave
Error, alsa audio: failed to open alsa audio device:default: No such
file or directory
Segmentation fault
david@eurolap:~$ yoshimi -A -j
ALSA lib pcm_dmix.c:996:(snd_pcm_dmix_open) unable to open slave
Error, alsa audio: failed to open alsa audio device:default: No such
file or directory
Segmentation fault
david@eurolap:~$ yoshimi -J
Error, failed to start Alsa midi thread: 1
Error - bail out of AlsaEngine::Start()
Error, failed to cancel Alsa midi thread
So sad, failed to start MusicIO
Yoshimi stages a strategic retreat :-(
yoshimi: ../../src/xcb_lock.c:32: _XCBUnlockDisplay: Assertion
`dpy->xcb->partial_request == 0' failed.
Aborted
david@eurolap:~$
I don't think there should be a segfault just because it couldn't open
Alsa audio with JACK running ... ;-)
Back to 0.036 for now.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
8:10 a.m.
david wrote:
[ ... ]
Well, for what it's worth, here on a non-RT kernel but with RTPRIO set
properly in limits.conf, using jackdmp 1.9.2:
david@eurolap:~$ yoshimi
Error, failed to start Alsa midi thread: 1
Define "properly", when a pthread_create asking for SCHED_FIFO returns
'1',
indicating 'No permission to set the scheduling policy and parameters specified
in attr'.
[ ... ]
yoshimi: ../../src/xcb_lock.c:32: _XCBUnlockDisplay: Assertion
`dpy->xcb->partial_request == 0' failed.
I've no idea where an _XCBUnlockDisplay assert might come from. I've never ever
seen one so I don't believe it's my doing.
[ ... ]
david@eurolap:~$ yoshimi -A -a
ALSA lib pcm_dmix.c:996:(snd_pcm_dmix_open) unable to open slave
Error, alsa audio: failed to open alsa audio device:default: No such
file or directory
Segmentation fault
Again, I don't see anything like this on my system with -A -a.
david@eurolap:~$ yoshimi -A -j
ALSA lib pcm_dmix.c:996:(snd_pcm_dmix_open) unable to open slave
Error, alsa audio: failed to open alsa audio device:default: No such
file or directory
Segmentation fault
Or with -A -j.
[ ... ]
I don't think there should be a segfault just because it couldn't open
Alsa audio with JACK running ... ;-)
Agreed. I can't reproduce it on my system.
Back to 0.036 for now.
Again, whatever works for you.
Cheers.
1:55 p.m.
david wrote:
cal wrote:
Clarification:
limits.conf contains:
@audio hard rtprio 50
@audio soft rtprio 30
@audio rtprio 100
Will try yoshimi on musicbox, it has RT kernel.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
For better or worse, there's an 0.053-pre3 on
<http://www.graggrag.com/?q=yoshimi>.
The settings corruption seems fixed, and some stray chaos from the recorder
reorg seems to be under control.
Well, for what it's worth, here on a non-RT kernel but with RTPRIO set
properly in limits.conf, using jackdmp 1.9.2:
2:06 p.m.
david wrote:
[ ... ]
Clarification:
limits.conf contains:
@audio hard rtprio 50
@audio soft rtprio 30
These are rather low. I just looked, and yoshi tries for 55, so these settings
would fail. You could either bump those settings higher, or adjust the value
in MusicIO.cpp line 214 down to your level and see if that helps.
@audio rtprio 100
That one looks odd, invalid syntax as far I can tell.
Will try yoshimi on musicbox, it has RT kernel.
With or without an rt kernel, the rules for the above settings don't change.
Cheers.
21 Jan
21 Jan
3:32 a.m.
cal wrote:
Thanks, I'll drop it. It was also a copy/paste.
Musicbox is running a music/multimedia focussed distro called ActiveX,
based on Ubuntu Studio. I expect its limits.conf is more likely to be
set up correctly than my copy/paste attempts on my ordinary laptop
setup! ;-)
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
david wrote:
I'll boost mine up to go with toshi. It was a copy/paste from someone
else's recommendation.
[ ... ]
Clarification:
limits.conf contains:
@audio hard rtprio 50
@audio soft rtprio 30
These are rather low. I just looked, and yoshi tries for 55, so these settings
would fail. You could either bump those settings higher, or adjust the value
in MusicIO.cpp line 214 down to your level and see if that helps. @audio
rtprio 100
That one looks odd, invalid syntax as far I can tell. Will try
yoshimi on musicbox, it has RT kernel.
With or without an rt kernel, the rules for the above settings don't change.
3:51 a.m.
david wrote:
[ ... ]
I'll boost mine up to go with toshi. It was a copy/paste from someone
else's recommendation.
I still get the feeling you're inclined to set them lower than what's
consider normal or recommended. The Jack FAQ spells it out pretty
simply - <http://www.jackaudio.org/faq>.
cheers.
@audio
hard rtprio 50
@audio soft rtprio 30
These are rather low. I just looked,
and yoshi tries for 55, so these settings
would fail. You could either bump those settings higher, or adjust the value
in MusicIO.cpp line 214 down to your level and see if that helps.
10:16 a.m.
cal wrote:
david wrote:
Thanks. I changed the hard one to 99. The JACK FAQ didn't say anything
about the difference between "hard" and "soft", so I set the
"soft" one
to 55. Can't test it right now, will test it later!
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
[ ... ]
I'll boost
mine up to go with toshi. It was a copy/paste from someone
else's recommendation.
I still get the feeling you're inclined to set them lower than what's
consider normal or recommended. The Jack FAQ spells it out pretty
simply - <http://www.jackaudio.org/faq>. @audio
hard rtprio 50
@audio soft rtprio 30
These are rather low. I just looked,
and yoshi tries for 55, so these settings
would fail. You could either bump those settings higher, or adjust the value
in MusicIO.cpp line 214 down to your level and see if that helps.
3:55 p.m.
david wrote:
cal wrote:
Almost, but not quite. Somewhere in limits.conf it describes (perhaps
cryptically)
how you can set hard and soft at the same time (on the same line) using the '-'.
I don't know of any reason to have hard and soft set different, so as per the jack
faq is about as good as you can get.
cheers.
david wrote:
Thanks. I changed the hard one to 99. The JACK FAQ didn't say anything
about the difference between "hard" and "soft", so I set the
"soft" one
to 55. Can't test it right now, will test it later!
[ ... ]
I still get the feeling you're inclined to set them
lower than what's
consider normal or recommended. The Jack FAQ spells it out pretty
simply - <http://www.jackaudio.org/faq>. > @audio hard rtprio 50
> @audio soft rtprio 30
These are rather low. I just looked, and yoshi tries for 55, so these settings
would fail. You could either bump those settings higher, or adjust the value
in MusicIO.cpp line 214 down to your level and see if that helps.
I'll boost
mine up to go with toshi. It was a copy/paste from someone
else's recommendation.
10:11 p.m.
cal wrote:
david wrote:
With hard and soft both set to 99, yoshimi 0.053 is busy making happy
noises for me!
Interesting difference between Zyn and Yoshimi here. Zyn has a Reverb
effect set, and shows it. Yoshimi shows "No effect". I don't think I
picked any effect in Zyn, I think that's just the way it came.
No prb, glad to have an updated Yoshimi running around! Cal =
Excellent! :-)
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
cal wrote:
Almost, but not quite. Somewhere in limits.conf it describes (perhaps
cryptically)
how you can set hard and soft at the same time (on the same line) using the '-'.
I don't know of any reason to have hard and soft set different, so as per the jack
faq is about as good as you can get. david wrote:
Thanks. I changed the hard one to
99. The JACK FAQ didn't say anything
about the difference between "hard" and "soft", so I set the
"soft" one
to 55. Can't test it right now, will test it later!
[ ... ]
>> @audio hard rtprio 50
>> @audio soft rtprio 30
> These are rather low. I just looked, and yoshi tries for 55, so these settings
> would fail. You could either bump those settings higher, or adjust the value
> in MusicIO.cpp line 214 down to your level and see if that helps.
I'll boost mine up to go with toshi. It was a copy/paste from someone
else's recommendation.
I still get the feeling you're inclined to set them
lower than what's
consider normal or recommended. The Jack FAQ spells it out pretty
simply - <http://www.jackaudio.org/faq>. 
23 Jan
23 Jan
9:17 a.m.
On Thu, Jan 21, 2010 at 06:05:20AM +1100, cal wrote:
--
torben Hohn
david wrote:
does yoshimi add such high priority threads also when its using jack ?
jack2 runs its stuff at prio 20. if yoshimi is doing stuff at higher
priorities, it can potentially cause xruns.
[ ... ]
Clarification:
limits.conf contains:
@audio hard rtprio 50
@audio soft rtprio 30
These are rather low. I just looked, and yoshi tries for 55, so these settings
would fail. You could either bump those settings higher, or adjust the value
in MusicIO.cpp line 214 down to your level and see if that helps. @audio rtprio 100
That one looks odd, invalid syntax as far I can tell.
Will try yoshimi on musicbox, it has RT kernel.
With or without an rt kernel, the rules for the above settings don't change.
Cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:32 a.m.
torbenh wrote:
[ ... ]
does yoshimi add such high priority threads also when its using jack ?
jack2 runs its stuff at prio 20. if yoshimi is doing stuff at higher
priorities, it can potentially cause xruns.
high priority? I thought the common case was to run jack a lot higher
than 20, and comfortably above 50-55. That's the way I've always done it,
but I'm open to enlightenment.
Cheers.
.
6:32 p.m.
On Sun, Jan 24, 2010 at 01:32:34AM +1100, cal wrote:
torbenh wrote:
please have a look at /usr/include/jack/thread.h
int jack_client_real_time_priority (jack_client_t*);
[ ... ]
does yoshimi add such high priority threads also when its using jack ?
jack2 runs its stuff at prio 20. if yoshimi is doing stuff at higher
priorities, it can potentially cause xruns.
high priority? I thought the common case was to run jack a lot higher
than 20, and comfortably above 50-55. That's the way I've always done it,
but I'm open to enlightenment.
Cheers.
.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
9:32 p.m.
torbenh wrote:
On Sun, Jan 24, 2010 at 01:32:34AM +1100, cal wrote:
An excellent little pick up, thank you torbenh! 0.053.2 does it better,
conforming to jack's firm recommendation on the topic.
cheers.
torbenh wrote:
please have a look at /usr/include/jack/thread.h
int jack_client_real_time_priority (jack_client_t*); [ ... ]
does yoshimi add such high priority threads also when its using jack ?
jack2 runs its stuff at prio 20. if yoshimi is doing stuff at higher
priorities, it can potentially cause xruns.
high priority? I thought the common
case was to run jack a lot higher
than 20, and comfortably above 50-55. That's the way I've always done it,
but I'm open to enlightenment.
24 Jan
24 Jan
1:25 a.m.
cal wrote:
torbenh wrote:
Cool, just did some playing here with no xruns at all. Good for no RT
kernel, I guess!
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Sun, Jan 24, 2010 at 01:32:34AM +1100, cal
wrote:
An excellent little pick up, thank you torbenh! 0.053.2 does it better,
conforming to jack's firm recommendation on the topic.
cheers. torbenh wrote:
please have a look at /usr/include/jack/thread.h
int jack_client_real_time_priority (jack_client_t*); [ ... ]
does yoshimi add such high priority threads also when its using jack ?
jack2 runs its stuff at prio 20. if yoshimi is doing stuff at higher
priorities, it can potentially cause xruns.
high priority? I thought the common
case was to run jack a lot higher
than 20, and comfortably above 50-55. That's the way I've always done it,
but I'm open to enlightenment. 
6:41 a.m.
torbenh wrote:
On Thu, Jan 21, 2010 at 06:05:20AM +1100, cal wrote:
Should limits.conf be different for
Jack1 then for Jack2?
\r
david wrote:
does yoshimi add such high priority threads also when its using jack ?
jack2 runs its stuff at prio 20. if yoshimi is doing stuff at higher
priorities, it can potentially cause xruns. [ ... ]
Clarification:
limits.conf contains:
@audio hard rtprio 50
@audio soft rtprio 30
These are rather low. I just looked, and yoshi tries for 55, so these
settings
would fail. You could either bump those settings higher, or adjust the value
in MusicIO.cpp line 214 down to your level and see if that helps.
7:07 a.m.
rosea grammostola wrote:
[ ... ]
No. Torben's tip resolves the issue in 0.053.2, which uses whatever jack
says it should use if that's lower than 50, otherwise it goes for 50.
How that's going to go on the alsa threads is still a wonder.
cheers.
does yoshimi add such high priority threads also
when its using jack ?
jack2 runs its stuff at prio 20. if yoshimi is doing stuff at higher
priorities, it can potentially cause xruns.
Should limits.conf be different for
Jack1 then for Jack2? 
29 Jan
29 Jan
12:16 p.m.
I don't know if this is known:
Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
many keys (~10) at the same time on my midi keyboard.
This does not happen with yoshimi 038
--
E.R.
2:05 p.m.
On Fri, 29 Jan 2010 18:16:03 +0100
Emanuel Rumpf <xbran(a)web.de> wrote:
I don't know if this is known:
Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
many keys (~10) at the same time on my midi keyboard.
This does not happen with yoshimi 038
Cant repeat that here. Are you using jack-midi or alsa-midi? I'm using
alsa-midi.
I can stick both arms down flat across the keyboard without it
disconnecting - get rather a lot of xruns though!
--
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.
2:24 p.m.
Folderol wrote:
On Fri, 29 Jan 2010 18:16:03 +0100
Emanuel Rumpf <xbran(a)web.de> wrote:
Hmmm, I've noticed that if I have a lot of notes going (play fast scales
with sustain pedal down), adding new notes will cut off existing ones.
Last night I was playing something into Rosegarden, and noticed that
sometimes a run of notes simply wouldn't happen - appear in Rosegarden
or play through Yoshimi.
I didn't get any xruns, and didn't see any messages from JACK about any
problems.
Using JACKDMP using alsa-midi (E-Mu XMidiPort 1x1 over USB 2 port and an
external USB sound card hooked to a different USB port). Yoshimi 0.053.2.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
I don't know if this is known:
Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
many keys (~10) at the same time on my midi keyboard.
This does not happen with yoshimi 038
Cant repeat that here. Are you using jack-midi or alsa-midi? I'm using
alsa-midi.
I can stick both arms down flat across the keyboard without it
disconnecting - get rather a lot of xruns though!
2:33 p.m.
On Fri, 29 Jan 2010 09:24:51 -1000
david <gnome(a)hawaii.rr.com> wrote:
Folderol wrote:
That's normal behaviour and dependent on the number of notes of
polyphony set at compile time ( haven't a clue what the default is) and
the release time of the notes.
On Fri, 29 Jan 2010 18:16:03 +0100
Emanuel Rumpf <xbran(a)web.de> wrote:
Hmmm, I've noticed that if I have a lot of notes going (play fast scales
with sustain pedal down), adding new notes will cut off existing ones. I don't know if this is known:
Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
many keys (~10) at the same time on my midi keyboard.
This does not happen with yoshimi 038
Cant repeat that here. Are you using jack-midi or alsa-midi? I'm using
alsa-midi.
I can stick both arms down flat across the keyboard without it
disconnecting - get rather a lot of xruns though! Last night I was playing something into Rosegarden,
and noticed that
sometimes a run of notes simply wouldn't happen - appear in Rosegarden
or play through Yoshimi.
If they don't even appear in Rosegarden then I wonder if you've got
MIDI set up correctly. Is it a USB keyboard? I believe they are
inclined to have latency problems and you might just be overfilling the
'pipe' :o
I didn't get any xruns, and didn't see any
messages from JACK about any
problems.
Using JACKDMP using alsa-midi (E-Mu XMidiPort 1x1 over USB 2 port and an
external USB sound card hooked to a different USB port). Yoshimi 0.053.2.
Looks even more like a straight MIDI problem.
--
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.
2:39 p.m.
Folderol wrote:
It's a MIDI keyboard (Yamaha PSR225GM) without USB capability. The
XMidiPort provides 2 standard MIDI cables at one end and a standard USB
connector at the other. It is connected into a USB hub that has a number
of other things connected to it (none in active use).
I'll have to try it without Yoshi running.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Fri, 29 Jan 2010 09:24:51 -1000
david <gnome(a)hawaii.rr.com> wrote:
Yoshimi is set for 256, I think that's the default.
Folderol wrote:
That's normal behaviour and dependent on the number of notes of
polyphony set at compile time ( haven't a clue what the default is) and
the release time of the notes. On Fri, 29 Jan 2010 18:16:03 +0100
Emanuel Rumpf <xbran(a)web.de> wrote:
Hmmm, I've noticed that if I
have a lot of notes going (play fast scales
with sustain pedal down), adding new notes will cut off existing ones. I don't know if this is known:
Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
many keys (~10) at the same time on my midi keyboard.
This does not happen with yoshimi 038
Cant repeat that here. Are you using jack-midi or alsa-midi? I'm using
alsa-midi.
I can stick both arms down flat across the keyboard without it
disconnecting - get rather a lot of xruns though! Last night I
was playing something into Rosegarden, and noticed that
sometimes a run of notes simply wouldn't happen - appear in Rosegarden
or play through Yoshimi.
If they don't even appear in Rosegarden then I wonder if you've got
MIDI set up correctly. Is it a USB keyboard? I believe they are
inclined to have latency problems and you might just be overfilling the
'pipe' :o I didn't
get any xruns, and didn't see any messages from JACK about any
problems.
Using JACKDMP using alsa-midi (E-Mu XMidiPort 1x1 over USB 2 port and an
external USB sound card hooked to a different USB port). Yoshimi 0.053.2.
Looks even more like a straight MIDI problem.
3:18 p.m.
On Fri, 29 Jan 2010 09:39:51 -1000
david <gnome(a)hawaii.rr.com> wrote:
Folderol wrote:
Hmmm. I usually go through a 'real' MIDI port.
OK, just tried going via the MidiSport 2x2 playing two-handed arpeggios
as fast as I can, and recording in Rosegarden. The only missing notes
as far as I can tell are ones I didn't hit!
I wonder if your hub is a proper 'high speed' one or just claims to be
USB2 compatible and down-converts to USB1. Have you tried it without
the hub?
--
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.
If they don't even appear in Rosegarden then
I wonder if you've got
MIDI set up correctly. Is it a USB keyboard? I believe they are
inclined to have latency problems and you might just be overfilling the
'pipe' :o
It's a MIDI keyboard (Yamaha PSR225GM) without USB capability. The
XMidiPort provides 2 standard MIDI cables at one end and a standard USB
connector at the other. It is connected into a USB hub that has a number
of other things connected to it (none in active use).
30 Jan
30 Jan
1:33 a.m.
Folderol wrote:
On Fri, 29 Jan 2010 09:39:51 -1000
david <gnome(a)hawaii.rr.com> wrote:
My laptops don't have 'real' MIDI ports. One of the desktop machines
does, courtesy of its Audiophile 2496, but I have no 'real' MIDI cables.
Folderol wrote:
Hmmm. I usually go through a 'real' MIDI port. If they don't even appear in Rosegarden then
I wonder if you've got
MIDI set up correctly. Is it a USB keyboard? I believe they are
inclined to have latency problems and you might just be overfilling the
'pipe' :o
It's a MIDI keyboard (Yamaha PSR225GM) without USB
capability. The
XMidiPort provides 2 standard MIDI cables at one end and a standard USB
connector at the other. It is connected into a USB hub that has a number
of other things connected to it (none in active use). OK, just tried going via the MidiSport 2x2 playing
two-handed arpeggios
as fast as I can, and recording in Rosegarden. The only missing notes
as far as I can tell are ones I didn't hit!
I wonder if your hub is a proper 'high speed' one or just claims to be
USB2 compatible and down-converts to USB1.
It's a proper high speed USB2 hub that claims to be compatible with
USB1.1. I have a USB2 scanner hooked up through it, and when I scan
high-res 24-bit color, it scans at USB2 speeds. Having accidentally used
it ONCE on a different machine that had only USB 1.1 ports, I *know* the
speed difference! ;-)
Have you tried it without the hub?
Not yet. I plan to.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
29 Jan
29 Jan
4:33 p.m.
2010/1/29 Folderol <folderol(a)ukfsn.org>rg>:
On Fri, 29 Jan 2010 18:16:03 +0100
Emanuel Rumpf <xbran(a)web.de> wrote:
I've connected the keyboard through jack-midi to yoshimi.
I think jackd kicks yoshi off, because it consumes too much time
in the rt-process then, although this doesn't really explain why it doesn't
happen with 038 that fast.
It just saw it with 038 too. Yoshi stopped for a moment,
but did not get disconnected from jackd, instead jackd reported some xruns.
I'm playing with a latency of 8ms, btw., at a rate of 48000.
A question pops up:
Which would be the most appropriate behavior,
when running out of time in the process thread ?
Stop processing voices ?
Process them, allowing to xrun ? No, I think.
Process them, but disconnect from jack ? No, I think.
Any other options ?
--
E.R.
I don't know if this is known:
Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
many keys (~10) at the same time on my midi keyboard.
This does not happen with yoshimi 038
Cant repeat that here. Are you using jack-midi or alsa-midi? I'm using
alsa-midi.
I can stick both arms down flat across the keyboard without it
disconnecting - get rather a lot of xruns though!
6:05 p.m.
Sorry to be late to this little party, but that's timezones for you ...
Emanuel Rumpf wrote:
2010/1/29 Folderol <folderol(a)ukfsn.org>rg>:
> On Fri, 29 Jan 2010 18:16:03 +0100
> Emanuel Rumpf <xbran(a)web.de> wrote:
>
>> I don't know if this is known:
>> Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
>> many keys (~10) at the same time on my midi keyboard.
>> This does not happen with yoshimi 038
>>
>>
> Cant repeat that here. Are you using jack-midi or alsa-midi? I'm using
> alsa-midi.
> I can stick both arms down flat across the keyboard without it
> disconnecting - get rather a lot of xruns though!
That's one of my standard QA tests, perhaps the only standard QA test I
regularly apply. Xruns I get, disconnects I don't.
I've connected the keyboard through jack-midi to
yoshimi.
I think jackd kicks yoshi off, because it consumes too much time
in the rt-process then, although this doesn't really explain why it doesn't
happen with 038 that fast.
That's puzzling, almost interesting. The main differences from 0.038 that I can
think of are a switch to pthread_create managing the priority setting on the
audio/midi threads, and some refinements to the locking when changes to parameter
controls are in progress. At face value
It just saw it with 038 too. Yoshi stopped for a
moment,
but did not get disconnected from jackd, instead jackd reported some xruns.
I'm playing with a latency of 8ms, btw., at a rate of 48000.
A question pops up:
Which would be the most appropriate behavior,
when running out of time in the process thread ?
Stop processing voices ?
Process them, allowing to xrun ? No, I think.
Process them, but disconnect from jack ? No, I think.
Any other options ?
A total rewrite of the synth? Sorry, not this little black duck!!
What we've got so far is a rewrite of the audio/midi drivers, but the core
synth engine remains as was apart from a few relatively minor efficiency/
performance refinements.
The concept of a wall clock for the process callback to keep a check on is
interesting (I have thought about it). Given the structure of
Master::MasterAudio(), your rule selection candidates don't really fit
what's currently going on in there, which brings us back to the total
rewrite question.
Since the wall clock thing has come up, one thing I am curious about is the
timing of the midi notes. At present, you can't have a note-on/note-off during
the generation of a buffer full of audio.
I'm inclined to agree with Will, that the cause of your grief seems more to do
with general midi issues rather than yoshi specific ones, though I will have
a think about the 038 -> 054-pre differences.
cheers, Cal
30 Jan
30 Jan
1:35 a.m.
Emanuel Rumpf wrote:
2010/1/29 Folderol <folderol(a)ukfsn.org>rg>:
Does using alsa-midi give you the same problem?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
On Fri, 29 Jan 2010 18:16:03 +0100
Emanuel Rumpf <xbran(a)web.de> wrote:
I've connected the keyboard through jack-midi to yoshimi.
I think jackd kicks yoshi off, because it consumes too much time
in the rt-process then, although this doesn't really explain why it doesn't
happen with 038 that fast.
It just saw it with 038 too. Yoshi stopped for a moment,
but did not get disconnected from jackd, instead jackd reported some xruns.
I'm playing with a latency of 8ms, btw., at a rate of 48000.
A question pops up:
Which would be the most appropriate behavior,
when running out of time in the process thread ?
Stop processing voices ?
Process them, allowing to xrun ? No, I think.
Process them, but disconnect from jack ? No, I think.
Any other options ? I don't know if this is known:
Yoshimi 054 pre2 and pre4 both disconnect from jack, when pressing
many keys (~10) at the same time on my midi keyboard.
This does not happen with yoshimi 038
Cant repeat that here. Are you using jack-midi or alsa-midi? I'm using
alsa-midi.
I can stick both arms down flat across the keyboard without it
disconnecting - get rather a lot of xruns though!
1:20 p.m.
2010/1/30 david <gnome(a)hawaii.rr.com>om>:
Does using alsa-midi give you the same problem?
Yes.
In the terminal there is this message:
Info, alsa midi port connected
Jack reports error: jack_client_thread zombified - exiting from JACK
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
Now - that's strange:
I found it happens with 038 too.
and:
It seems to depend on the instrument used:
The default sine-like tone doesn't cause an error,
but when using Rhodes/SynthRhodes2, pressing two keys at once
zombifies the jack process.
Is this reproducable?
Maybe one of the internal synths/effects is still not rt-safe.
--
E.R.
1:53 p.m.
Emanuel Rumpf wrote:
2010/1/30 david <gnome(a)hawaii.rr.com>om>:
Yep! I've already apologised to another poster that yesterday wasn't one
of my better days for clear-headedness, so same goes here.
Does using alsa-midi give you the same problem?
Yes.
In the terminal there is this message:
Info, alsa midi port connected
Jack reports error: jack_client_thread zombified - exiting from JACK
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
Now - that's strange:
I found it happens with 038 too.
and:
It seems to depend on the instrument used:
The default sine-like tone doesn't cause an error,
but when using Rhodes/SynthRhodes2, pressing two keys at once
zombifies the jack process.
Is this reproducable? Maybe one of the internal synths/effects is still not
rt-safe.
Looks to me like a straight deadlock, ie a lower level section waiting on a lock
while the lock is already held by it's caller. I'll work on it.
Cheers, and thanks for your patience. There are days when I fully qualify as a
muddle headed wombat.
3:07 p.m.
On Sun, 31 Jan 2010 05:53:35 +1100
cal <cal(a)graggrag.com> wrote:
Emanuel Rumpf wrote:
I find this all very strange. I don't seem to be having these problems.
I wonder what is different about my setup. I don't for one moment
think it's luck - luck and I are bitter enemies :o
--
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.
2010/1/30 david <gnome(a)hawaii.rr.com>om>:
Yep! I've already apologised to another poster that yesterday wasn't one
of my better days for clear-headedness, so same goes here.
Does using alsa-midi give you the same problem?
Yes.
In the terminal there is this message:
Info, alsa midi port connected
Jack reports error: jack_client_thread zombified - exiting from JACK
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
Now - that's strange:
I found it happens with 038 too.
and:
It seems to depend on the instrument used:
The default sine-like tone doesn't cause an error,
but when using Rhodes/SynthRhodes2, pressing two keys at once
zombifies the jack process.
Is this reproducable? Maybe one of the internal synths/effects is still
not rt-safe.
Looks to me like a straight deadlock, ie a lower level section waiting on a lock
while the lock is already held by it's caller. I'll work on it.
Cheers, and thanks for your patience. There are days when I fully qualify as a
muddle headed wombat.
4:33 p.m.
Folderol wrote:
[ ... ]
I find this all very strange. I don't seem to be having these problems.
I wonder what is different about my setup. I don't for one moment
think it's luck - luck and I are bitter enemies :o
And I believe you are quite right. In messing with the deadlock issue on
parameter save (0.054-pre4 only) I got all kinds of things confused. In
fact I can _not_ replicate the reported issue on Rhodes/SynthRhodes2 (or any
other instrument). The forearm test and the "two keys simultaneously" both
test fine for me ... well, as well as the forearm test ever does.
It's been a muddled couple of days here.
cheers, Cal
I found
it happens with 038 too.
and:
It seems to depend on the instrument used:
The default sine-like tone doesn't cause an error,
but when using Rhodes/SynthRhodes2, pressing two keys at once
zombifies the jack process.
Is this reproducable?
Yep! I've already apologised to another poster that
yesterday wasn't one
of my better days for clear-headedness, so same goes here.
Maybe one of the internal synths/effects is still
not rt-safe.
Looks to me like a straight deadlock, ie a lower level section waiting
on a lock
while the lock is already held by it's caller. I'll work on it.
Cheers, and thanks for your patience. There are days when I fully qualify as a
muddle headed wombat.
31 Jan
31 Jan
11:42 a.m.
2010/1/30 cal <cal(a)graggrag.com>om>:
And I believe you are quite right. In messing with the deadlock issue on
parameter save (0.054-pre4 only) I got all kinds of things confused. In
fact I can _not_ replicate the reported issue on Rhodes/SynthRhodes2 (or any
other instrument). The forearm test and the "two keys simultaneously" both
test fine for me ... well, as well as the forearm test ever does.
Hm.
I installed a recent version of jack (jack2).
Now it doesn't disconnect from jack anymore, when playing SynthRhodes2,
but it causes xruns, and quite audible distortion
when pressing ~3 keys at the same time.
There must be missing anything.
It's been a muddled couple of days here.
Take a break, Cal. Re-think
it after some days.
Thanks for the efforts.
--
E.R.
20 Jan
20 Jan
7:19 a.m.
cal wrote:
For better or worse, there's an 0.053-pre3 on
<http://www.graggrag.com/?q=yoshimi>.
The settings corruption seems fixed, and some stray chaos from the recorder
reorg seems to be under control.
In the vague hope that it might help when I stuff things up, I've put up an
0.053-pre2-0.053-pre3.diff as well.
Can I do a feature request?
'open recent files' functionality and Ladi level 1 support? www.ladish.org
\r
8:11 a.m.
rosea grammostola wrote:
[ ... ]
Can I do a feature request?
'open recent files' functionality and Ladi level 1 support? www.ladish.org
I've been waiting for ladi to come up :-). If I can figure it out I might
give it a go. At face value it does have some attraction.
What 'recent files' are you interested in revisiting, instruments or what?
Cheers.
12:07 p.m.
On Wed, 20 Jan 2010 23:32:57 +1100
cal <cal(a)graggrag.com> wrote:
rosea grammostola wrote:
If I can jump in here :)
I would very much like to see recent .xmz files remembered as there are
the only ones I'm really likely to want to re-load. Having said that
yoshimi used to remember which was the last bank collection I used, but
now seems to have developed amnesia :'(
Thinking about it I remember that not all versions of Zyn remember
either!
And now the good news :D
No more problems finding banks etc.
Recording works fine for me. I like the triggering options and
especially the fact that you get immediate visual feedback of exactly
what state it is in.
--
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.
[ ... ]
Can I do a feature request?
'open recent files' functionality and Ladi level 1 support? www.ladish.org
I've been waiting for ladi to come up :-). If I can figure it out I might
give it a go. At face value it does have some attraction.
What 'recent files' are you interested in revisiting, instruments or what?
Cheers.
12:28 p.m.
Folderol wrote:
[ ... ]
If I can jump in here :)
Of course you can!
I would very much like to see recent .xmz files
remembered as there are
the only ones I'm really likely to want to re-load.
Yep, that'd be nice. Can't promise I'll actually take it on, but ideas on
how it should look and work would be welcome. You never know, I might just
get motivated to try it.
... Having said that
yoshimi used to remember which was the last bank collection I used, but
now seems to have developed amnesia :'(
Thinking about it I remember that not all versions of Zyn remember
either!
I've been wondering where the 'last bank' recall went to too. I'll look
into it.
And now the good news :D
No more problems finding banks etc.
Recording works fine for me. I like the triggering options and
especially the fact that you get immediate visual feedback of exactly
what state it is in.
Excellent. I think it really was just you & me that wanted the record facility,
and now we're both happy with it so life's good!
cheers.
10:38 p.m.
Folderol wrote:
[ ... ] Having said that
yoshimi used to remember which was the last bank collection I used, but
now seems to have developed amnesia :'(
Thinking about it I remember that not all versions of Zyn remember
either!
Another victim of the sloppy reshuffle, hence
<http://www.graggrag.com/yoshimi/yoshimi-0.053-pre4.tar.bz2>
There's a couple of minor method movements in there too, so be alert (but
not alarmed).
Cheers.
21 Jan
21 Jan
9:34 p.m.
cal wrote:
Folderol wrote:
Hmmm, http://www.graggrag.com/?q=yoshimi still showing
yoshimi-0.053.tar.bz2, or has the -pre4 now become the full blow .053?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
[ ... ] Having said that
yoshimi used to remember which was the last bank collection I used, but
now seems to have developed amnesia :'(
Thinking about it I remember that not all versions of Zyn remember
either!
Another victim of the sloppy reshuffle, hence
<http://www.graggrag.com/yoshimi/yoshimi-0.053-pre4.tar.bz2>
There's a couple of minor method movements in there too, so be alert (but
not alarmed).
9:51 p.m.
david wrote:
[ ... ]
Hmmm, http://www.graggrag.com/?q=yoshimi still showing
yoshimi-0.053.tar.bz2, or has the -pre4 now become the full blow .053?
Under "Changes", it reads "0.053 2010-01-22 no change from
pre4".
10:12 p.m.
cal wrote:
david wrote:
'K, thanks.
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
[ ... ]
Hmmm, http://www.graggrag.com/?q=yoshimi still showing
yoshimi-0.053.tar.bz2, or has the -pre4 now become the full blow .053?
Under "Changes", it reads "0.053 2010-01-22 no change from
pre4". 
20 Jan
20 Jan
9:24 a.m.
Excerpts from cal's message of Wed Jan 20 07:39:17 +0100 2010:
For better or worse, there's an 0.053-pre3 on
<http://www.graggrag.com/?q=yoshimi>.
The settings corruption seems fixed, and some stray chaos from the recorder
reorg seems to be under control.
In the vague hope that it might help when I stuff things up, I've put up an
0.053-pre2-0.053-pre3.diff as well.
cheers, Cal
Hi Cal,
I just tried 0.053-pre3 very briefly and found one bug.
On the bottom of the main window there's a meter and next to it the
value in dB. It seems that the channels are at least turned around, so
when it goes into clipping on one channel the meter on the other channel
is somewhere near where 0dB probably is (which is also not very clear to
me..).
I found this with a patch that produces quite different levels on both
channels, 'Choir and Voice' -> 'Vocal Morph *'
I don't understand that meter, I guess the blue bar is peak, the yellow
one rms, but I don't know whether 0dB is at the right end of the meter
or at the thicker line before it. I also don't know whether the numbers
correspond to rms or peak.
Well, just thought I let you know :)
Yoshi is already quite different from zyn imho, and not worse, despite
the one or the other quirk. And most importantly: it's worked on, so it
has potential for improvement.
Regards,
Philipp
12:12 p.m.
Philipp Überbacher wrote:
[ ... ]
I just tried 0.053-pre3 very briefly and found one bug.
On the bottom of the main window there's a meter and next to it the
value in dB. It seems that the channels are at least turned around, so
when it goes into clipping on one channel the meter on the other channel
is somewhere near where 0dB probably is (which is also not very clear to
me..).
I found this with a patch that produces quite different levels on both
channels, 'Choir and Voice' -> 'Vocal Morph *'
I don't understand that meter, I guess the blue bar is peak, the yellow
one rms, but I don't know whether 0dB is at the right end of the meter
or at the thicker line before it. I also don't know whether the numbers
correspond to rms or peak.
To be honest, I don't understand the meter all that well either. Last time
I messed with it, I stuffed it completely so very quickly put it back the
way it was. The bluish bar is a calculated "dB", and the yellow line is rms.
From a quick look at the code and watching Vocal Morph
in action, I suspect
you might be right - it does appear the peak indicators might
be transposed.
But then it's 4am and I can't sleep, so now's not the time for me to be
messing with code (even "simple" code).
Well, just thought I let you know :)
Yoshi is already quite different from zyn imho, and not worse, despite
the one or the other quirk. And most importantly: it's worked on, so it
has potential for improvement.
Appreciated. It is a strange beast, invoking strange relationships.
Cheers.
5203
days inactive
5214
days old
linux-audio-user@lists.linuxaudio.org
45 comments
8 participants
participants (8)
-
Atte André Jensen -
cal -
david -
Emanuel Rumpf -
Folderol -
Philipp Überbacher -
rosea grammostola -
torbenh