13 Oct
2009
13 Oct
'09
1:10 a.m.
Frank Kober wrote:
Hi there,
I just noticed that I'm not able to save sounds to my custom root bank directory,
and wondered if I did something wrong setting this up in my home. Also, when I
try to change the name of the current sound with a right click, the dialog opens
OK and lets me enter the patch name, but it won't keep it when I click OK.
Any idea? I thought about my bank dir file permissions, but they seem to be OK.
I'm not sure, but I think that this worked already with yoshimi. I cannot tell the
last version with which it did though...
Right click instrument name change now works. For me, saving to a custom bank root
seems ok, but some funkiness there wouldn't greatly surprise me. If it still
doesn't
satisfy, perhaps you can spell out the steps you're taking and from that I'll
hopefully be able to figure out where it's going wrong.
0.021 fix right click instrument rename and a couple of bank management issues
<http://www.graggrag.com/?q=yoshimi>
cheers, Cal
13 Oct
13 Oct
11:03 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
That was ugly. Bank management is now somewhat improved. But wait, there's more.
I've previously mentioned the "three tries for mutex" theory. Yesterday I
noticed
that it was actually disabled. I'm a little surprised at how well the little beast
has performed while demanding the lock in the process callback :-). It's been that
way for a week or two. Enabling it again looks mildly interesting. From what I'm
seeing, it looks like the main source of missed locks is control/file actions.
Perchance we'll see less xruns in those situations now. But expect anything.
0.022 more bank management fixes
<http://www.graggrag.com/?q=yoshimi>
cheers, Cal
5:01 p.m.
New subject: yet another yoshimi bug fix, -> 0.022
On Wed, 2009-10-14 at 00:02 +1100, cal wrote:
0.022 more bank management fixes
<http://www.graggrag.com/?q=yoshimi>
cheers, Cal
For a while, having multiple banks of the same name has not worked
properly. Originally there would be numbered duplicates shown in the
list, but now (I don't know which exact version) only one is shown. This
probably wouldn't be a problem, but the actual bank selected is
different to the name selected in the list, as if it is going by the
list-with-duplicates.
Another issue I've found is that the pitch-bend controller is offset by
some pitch. Sending a pitch bend of 0 results in a pitch one whole-note
higher than it should be.
Good work though...
Peter.
5:15 p.m.
New subject: yet another yoshimi bug fix, -> 0.022
Peter Nelson wrote:
On Wed, 2009-10-14 at 00:02 +1100, cal wrote:
not sure what you mean there. While the selected instrument
shown on the
Master panel isn't refreshing properly, I thought 0.022 had the handling of
duplicate names under control. I'll go through it again later today.
0.022 more bank management fixes
<http://www.graggrag.com/?q=yoshimi>
cheers, Cal
For a while, having multiple banks of the same name has not worked
properly. Originally there would be numbered duplicates shown in the
list, but now (I don't know which exact version) only one is shown. This
probably wouldn't be a problem, but the actual bank selected is
different to the name selected in the list, as if it is going by the
list-with-duplicates. Another issue I've found is that the pitch-bend
controller is offset by
some pitch. Sending a pitch bend of 0 results in a pitch one whole-note
higher than it should be.
is that with alsa or jack midi (or both?)
Good work though...
yeah, maybe ... struggling, and it's all a bit too ragged for my liking.
5:20 p.m.
New subject: yet another yoshimi bug fix, -> 0.022
On Wed, 2009-10-14 at 06:15 +1100, cal wrote:
Hmm, just tested that and it's only with jack midi.
Peter.
Peter Nelson wrote:
I mean it picks the item in the list that would've been shown there if
it showed the duplicates.
For a while, having multiple banks of the same
name has not worked
properly. Originally there would be numbered duplicates shown in the
list, but now (I don't know which exact version) only one is shown. This
probably wouldn't be a problem, but the actual bank selected is
different to the name selected in the list, as if it is going by the
list-with-duplicates.
not sure what you mean there. While the selected instrument
shown on the
Master panel isn't refreshing properly, I thought 0.022 had the handling of
duplicate names under control. I'll go through it again later today. Another issue
I've found is that the pitch-bend controller is offset by
some pitch. Sending a pitch bend of 0 results in a pitch one whole-note
higher than it should be.
is that with alsa or jack midi (or both?)
10:37 p.m.
New subject: yet another yoshimi bug fix, -> 0.022
cal wrote:
Peter Nelson wrote:
One bit too far ...
--- yoshimi-dev.orig/src/MusicIO/JackEngine.cpp
+++ yoshimi-dev/src/MusicIO/JackEngine.cpp
@@ -478,7 +478,7 @@
case 0xE0: // pitch bend
ctrltype = C_pitchwheel;
- par = ((midi.data[2] << 8) | midi.data[1]) - 8192;
+ par = ((midi.data[2] << 7) | midi.data[1]) - 8192;
setMidiController(channel, ctrltype, par);
break;
Looking back over the last two weeks I really shouldn't have been attempting
code changes, and I certainly shouldn't have been posting the results. People
have been remarkably tolerant, and for that I very grateful.
cheers.
[ ... ]
Another issue I've found is that the pitch-bend controller is offset by
some pitch. Sending a pitch bend of 0 results in a pitch one whole-note
higher than it should be.
You're right - not good. 
11:32 p.m.
New subject: yet another yoshimi bug fix, -> 0.022
Looking back over the last two weeks I really
shouldn't have been attempting
code changes, and I certainly shouldn't have been posting the results. People
have been remarkably tolerant, and for that I very grateful.
cheers.
Cal, the tremendous quality of your work is worth it. I cannot describe
what happened to me when I first fired up Yoshimi and received real
reliable access to all that gorgeous tone-sculpture through my
keyboard. I greatly appreciate the care that goes into your code. As
for me, count me on your team :-)
Haven't found bugs in 0.022 yet, by the way, except the teeny one about
patch renames not showing up in the main window.
J.E.B.
14 Oct
14 Oct
1:06 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
Jonathan E. Brickman wrote:
[ ... ]
Haven't found bugs in 0.022 yet, by the way,
except the teeny one about
patch renames not showing up in the main window.
Just had a look at Zyn 2.4.0, and it behaves the same. The renamed patch doesn't
update in the main window until you click on the renamed slot with READ checked.
Instant update would be nice, but a bit tricky.
cheers.
1:34 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
cal wrote:
Jonathan E. Brickman wrote:
[ ... ]
Perhaps not so hard.
0.023 fix jack midi pitchbend, update master panel instrument label on bank slot rename
<http://www.graggrag.com/?q=yoshimi>
cheers.
Haven't found bugs in 0.022 yet, by the way,
except the teeny one about
patch renames not showing up in the main window.
Just had a look at Zyn 2.4.0, and it behaves the same. The renamed patch doesn't
update in the main window until you click on the renamed slot with READ checked.
Instant update would be nice, but a bit tricky. 
7:55 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
Am Mittwoch 14 Oktober 2009 05:34:24 schrieb cal:
cal wrote:
Since your first announcement of yoshimi here i've been downloading and
compiling several versions sucessfully, but haven't been able to run it.
I get an immediate segmentation fault, now finally i found some time to look
into what's happening, via gdb. Here's the backtrace and output of "l"
(list)
from gdb, i'll happily do whatever is needed to provide more info as time
permits:
ed@edpc:~/Documents/src/Synth/yoshimi-0.022> gdb yoshimi
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>...
(gdb) r
Starting program: /home/ed/Documents/src/Synth/yoshimi-0.022/yoshimi
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x0813372b in PresetsStore::PresetsStore() ()
Current language: auto; currently asm
(gdb) bt
#0 0x0813372b in PresetsStore::PresetsStore() ()
#1 0x081337ef in global constructors keyed to presetsstore ()
#2 0x0815760d in __do_global_ctors_aux ()
#3 0x0807a53c in _init ()
#4 0x081574c9 in __libc_csu_init (argc=1, argv=0xafffed14, envp=0xafffed1c)
at elf-init.c:79
#5 0xa790c69c in __libc_start_main () from /lib/libc.so.6
#6 0x0807ba41 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb) l
1 /tmp/ccr5yeuc.s: No such file or directory.
in /tmp/ccr5yeuc.s
(gdb)
I should add that i modified src/Params/PresetsStore.cpp a bit (without
understanding much of what i was doing, I don't know C++ well) - here's the
diff, but it didn't make a difference in gdb output anyway... :
--- src/Params/PresetsStore.cpp.orig 2009-10-13 11:56:30.000000000 +0200
+++ src/Params/PresetsStore.cpp 2009-10-14 11:49:44.000000000 +0200
@@ -30,9 +30,9 @@
#include "Params/PresetsStore.h"
PresetsStore presetsstore;
+string preset_extension = ".xpz";
-PresetsStore::PresetsStore() :
- preset_extension(".xpz")
+PresetsStore::PresetsStore()
{
clipboard.data = NULL;
clipboard.type.clear();
openSUSE 11.1, gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)
Ah, and zynaddsubfx from git compiles and runs, fwiw.
Edgar
Jonathan E. Brickman wrote:
[ ... ]
Perhaps not so hard.
0.023 fix jack midi pitchbend, update master panel instrument label on
bank slot rename
<http://www.graggrag.com/?q=yoshimi>
cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Haven't found bugs in 0.022 yet, by the way,
except the teeny one about
patch renames not showing up in the main window.
Just had a look at Zyn 2.4.0, and it behaves the same. The renamed patch
doesn't update in the main window until you click on the renamed slot
with READ checked. Instant update would be nice, but a bit tricky.
8:17 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
Edgar Aichinger wrote:
Am Mittwoch 14 Oktober 2009 05:34:24 schrieb cal:
Umm,
you're somewhat alone in this, which could suggest a local problem.
cal wrote:
Since your first announcement of yoshimi here i've been downloading and
compiling several versions sucessfully, but haven't been able to run it. Jonathan E. Brickman wrote:
[ ... ]
Perhaps not so
hard.
0.023 fix jack midi pitchbend, update master panel instrument label on
bank slot rename
<http://www.graggrag.com/?q=yoshimi>
cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Haven't found bugs in 0.022 yet, by the way,
except the teeny one about
patch renames not showing up in the main window.
Just had a look at Zyn 2.4.0, and
it behaves the same. The renamed patch
doesn't update in the main window until you click on the renamed slot
with READ checked. Instant update would be nice, but a bit tricky.
I get an immediate segmentation fault, now finally i found some time to look
into what's happening, via gdb. Here's the backtrace and output of "l"
(list)
from gdb, i'll happily do whatever is needed to provide more info as time
permits:
ed@edpc:~/Documents/src/Synth/yoshimi-0.022> gdb yoshimi
that doesn't seem
to lead anywhere useful.
[ ... ]
Starting program:
/home/ed/Documents/src/Synth/yoshimi-0.022/yoshimi
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x0813372b in PresetsStore::PresetsStore() ()
Current language: auto; currently asm
(gdb) bt
#0 0x0813372b in PresetsStore::PresetsStore() ()
#1 0x081337ef in global constructors keyed to presetsstore ()
#2 0x0815760d in __do_global_ctors_aux ()
#3 0x0807a53c in _init ()
#4 0x081574c9 in __libc_csu_init (argc=1, argv=0xafffed14, envp=0xafffed1c)
at elf-init.c:79
#5 0xa790c69c in __libc_start_main () from /lib/libc.so.6
#6 0x0807ba41 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb) l
1 /tmp/ccr5yeuc.s: No such file or directory.
in /tmp/ccr5yeuc.s
(gdb)
That's a bit low on entertainment, and information.
I should add that i modified
src/Params/PresetsStore.cpp a bit (without
understanding much of what i was doing, I don't know C++ well) - here's the
diff, but it didn't make a difference in gdb output anyway... :
--- src/Params/PresetsStore.cpp.orig 2009-10-13 11:56:30.000000000 +0200
+++ src/Params/PresetsStore.cpp 2009-10-14 11:49:44.000000000 +0200
@@ -30,9 +30,9 @@
#include "Params/PresetsStore.h"
PresetsStore presetsstore;
+string preset_extension = ".xpz";
-PresetsStore::PresetsStore() :
- preset_extension(".xpz")
+PresetsStore::PresetsStore()
{
clipboard.data = NULL;
clipboard.type.clear();
if you say so.
What are your build options - anything obvious like building with X86_64 flags on 32bit?
I dunno.
9 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
Am Mittwoch 14 Oktober 2009 12:16:50 schrieb cal:
Nah, while experimenting i tried to alter the 32bit flags with ccmake (using
-march=i686, -O2 or removing the -msse2 because i wasn't sure if my AthlonXP
CPU supports it) which led to even more problems. So i think they are in
effect, and I stayed with the flags ccmake determined by itself, "-O3 -
march=native -msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer"
Hm. Rather clueless now. Pretty weird...
Edgar
Edgar Aichinger wrote:
Too bad :(
Am Mittwoch 14 Oktober 2009 05:34:24 schrieb
cal:
Umm, you're somewhat alone in this, which could suggest a local problem.
cal wrote:
Since your first announcement of yoshimi here i've been downloading and
compiling several versions sucessfully, but haven't been able to run it. Jonathan E. Brickman wrote:
[ ... ]
> Haven't found bugs in 0.022 yet, by the way, except the teeny one
> about patch renames not showing up in the main window.
Just had a look at Zyn 2.4.0, and it behaves the same. The renamed
patch doesn't update in the main window until you click on the renamed
slot with READ checked. Instant update would be nice, but a bit tricky.
Perhaps not so hard.
0.023 fix jack midi pitchbend, update master panel instrument label on
bank slot rename
<http://www.graggrag.com/?q=yoshimi>
cheers.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user I get an immediate segmentation fault, now
finally i found some time to
look into what's happening, via gdb. Here's the backtrace and output of
"l" (list) from gdb, i'll happily do whatever is needed to provide more
info as time permits:
ed@edpc:~/Documents/src/Synth/yoshimi-0.022> gdb yoshimi
that doesn't seem to lead anywhere useful. [ ... ]
Yeah that's why i asked here, I don't really know how to supply more useful
information.
Starting program:
/home/ed/Documents/src/Synth/yoshimi-0.022/yoshimi
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x0813372b in PresetsStore::PresetsStore() ()
Current language: auto; currently asm
(gdb) bt
#0 0x0813372b in PresetsStore::PresetsStore() ()
#1 0x081337ef in global constructors keyed to presetsstore ()
#2 0x0815760d in __do_global_ctors_aux ()
#3 0x0807a53c in _init ()
#4 0x081574c9 in __libc_csu_init (argc=1, argv=0xafffed14,
envp=0xafffed1c) at elf-init.c:79
#5 0xa790c69c in __libc_start_main () from /lib/libc.so.6
#6 0x0807ba41 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb) l
1 /tmp/ccr5yeuc.s: No such file or directory.
in /tmp/ccr5yeuc.s
(gdb)
That's a bit low on entertainment, and information. I should add that i modified
src/Params/PresetsStore.cpp a bit (without
understanding much of what i was doing, I don't know C++ well) - here's
the diff, but it didn't make a difference in gdb output anyway... :
--- src/Params/PresetsStore.cpp.orig 2009-10-13 11:56:30.000000000
+0200 +++ src/Params/PresetsStore.cpp 2009-10-14 11:49:44.000000000 +0200
@@ -30,9 +30,9 @@
#include "Params/PresetsStore.h"
PresetsStore presetsstore;
+string preset_extension = ".xpz";
-PresetsStore::PresetsStore() :
- preset_extension(".xpz")
+PresetsStore::PresetsStore()
{
clipboard.data = NULL;
clipboard.type.clear();
if you say so.
What are your build options - anything obvious like building with X86_64
flags on 32bit? I dunno.
9:06 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
Edgar Aichinger wrote:
[ ... ]
Too bad :(
Can you make it accessible some other way?
I get an
immediate segmentation fault, now finally i found some time to
look into what's happening, via gdb. Here's the backtrace and output of
"l" (list) from gdb, i'll happily do whatever is needed to provide more
info as time permits:
ed@edpc:~/Documents/src/Synth/yoshimi-0.022> gdb yoshimi
that doesn't seem
to lead anywhere useful. [ ... ]
[...] and I stayed with the flags ccmake determined by itself, "-O3 -
march=native -msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer"
Hm. Rather clueless now. Pretty weird...
Yep, for 32 bitters that seems to work ok.
Most puzzling, I would like to help
you get it sorted, so if I think of anything I'll yell.
cheers.
10:15 a.m.
New subject: yet another yoshimi bug fix, -> 0.022
Nah, while experimenting i tried to alter the 32bit
flags with ccmake (using
-march=i686, -O2 or removing the -msse2 because i wasn't sure if my AthlonXP
CPU supports it) which led to even more problems. So i think they are in
effect, and I stayed with the flags ccmake determined by itself, "-O3 -
march=native -msse -msse2 -mfpmath=sse -ffast-math -fomit-frame-pointer"
Probably is it. Take out -msse and -msse2 and -mfpmath=sse, and see
what it does.
J.E.B.
12 May
12 May
10:10 p.m.
New subject: yet another yoshimi bug fix, -> 0.022
On Wed, 2009-10-14 at 10:53 +1100, cal wrote:
Peter Nelson wrote:
Hi,
This issue is back. I notice that 8192 was replaced by 4096 at some
point...
--
Peter
[ ... ]
Another issue I've found is that the pitch-bend controller is offset by
some pitch. Sending a pitch bend of 0 results in a pitch one whole-note
higher than it should be.
You're right - not good.
24 May
24 May
4:50 p.m.
New subject: yet another yoshimi bug fix, -> 0.057
On 13/05/10 06:10, Peter Nelson wrote:
On Wed, 2009-10-14 at 10:53 +1100, cal wrote:
Ooops. I could explain how that happened, but probably shouldn't. 8192 is back in
0.057,
along with a lazy signal response fix (courtesy Nedko), plus an attempt to detect sse
availability, stepping over things when it's not.
Sorry to be slow, moving house has had me off-planet/net for 3++ weeks. For various
reasons, I haven't been able to give it serious testing yet, but I don't expect
anything
too dramatic. It's possible though.
<http://www.graggrag.com/yoshimi/yoshimi-0.057.tar.bz2>
cheers, Cal
Peter Nelson wrote:
Hi,
This issue is back. I notice that 8192 was replaced by 4096 at some
point...
[ ... ]
Another issue I've found is that the pitch-bend controller is offset by
some pitch. Sending a pitch bend of 0 results in a pitch one whole-note
higher than it should be.
You're right - not good.
25 May
25 May
1:16 a.m.
New subject: yet another yoshimi bug fix, -> 0.057
On 25/05/10 00:50, cal wrote:
[ ... ]
<http://www.graggrag.com/yoshimi/yoshimi-0.057.tar.bz2>
Apologies for the link failure, a firewall setting slow to catch up with the relocation.
0.057 is now also on sourceforge <http://sourceforge.net/projects/yoshimi/files/>.
cheers, Cal
5090
days inactive
5314
days old
linux-audio-user@lists.linuxaudio.org
17 comments
4 participants
participants (4)
-
cal -
Edgar Aichinger -
Jonathan E. Brickman -
Peter Nelson