15 Sep
2009
15 Sep
'09
9:53 a.m.
A while back I floated a theory or two on how to improve ZynAddSubFX'
jack io. It has progressed to a fairly functional form, ie, no crackling,
and it generally keeps up with proceedings fairly well.
Thanks in no small part to the outstanding debugging efforts of James Morris,
most (if not all) of the accidental "colourations" to the generated sound
seem to have been resolved.
And the jack midi implementation no longer destroys the entire goal of jack
midi. I thought that was important.
Snapshot tarball at <http://www.graggrag.com/?q=node/19> for those interested.
Mark, if you're thinking of integrating the jack driver, I reckon this is
probably as good as I'm going to get it :-).
cheers, Cal
15 Sep
15 Sep
3:03 p.m.
cal wrote:
A while back I floated a theory or two on how to
improve ZynAddSubFX'
jack io. It has progressed to a fairly functional form, ie, no crackling,
and it generally keeps up with proceedings fairly well.
Thanks in no small part to the outstanding debugging efforts of James Morris,
most (if not all) of the accidental "colourations" to the generated sound
seem to have been resolved.
And the jack midi implementation no longer destroys the entire goal of jack
midi. I thought that was important.
Snapshot tarball at <http://www.graggrag.com/?q=node/19> for those interested.
Mark, if you're thinking of integrating the jack driver, I reckon this is
probably as good as I'm going to get it :-).
cheers, Cal
HI, Cal.
A quick test suggests that this version works really well : no crackles
no xruns here!
Great work!
regards, G.
6:05 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Tue, 15 Sep 2009 21:53:36 +1000
cal <cal(a)graggrag.com> wrote:
A while back I floated a theory or two on how to
improve ZynAddSubFX'
jack io. It has progressed to a fairly functional form, ie, no crackling,
and it generally keeps up with proceedings fairly well.
Thanks in no small part to the outstanding debugging efforts of James Morris,
most (if not all) of the accidental "colourations" to the generated sound
seem to have been resolved.
And the jack midi implementation no longer destroys the entire goal of jack
midi. I thought that was important.
Snapshot tarball at <http://www.graggrag.com/?q=node/19> for those interested.
Mark, if you're thinking of integrating the jack driver, I reckon this is
probably as good as I'm going to get it :-).
cheers, Cal
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Zynaddsubfx-user mailing list
Zynaddsubfx-user(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zynaddsubfx-user
Well I don't know if this was intended, but it's arrived in Linux
Audio, not Zyn!
Anyway, progress report :)
First stab at ccmake . gave the error 'Empty cache', but when I did a
plain cmake . by mistake, the repeated ccmake . lo and behold editable
fields magically appeared.
Anothe run as cmake . told my that 'unset' in CMakeLists.txt was not
recognised, so I commented out the three lines from No. 63.
After that I got the complaint that also was not there - well it damn
well is :) The script was being too optimistic. The alsa version I'm
running is 1.0.16 and changing the script to accept that seems to work.
Initial results running the synth are very good indeed. However there
is a problem with reverb -> initial delay. It always comes up at 40,
and changing the control has no effect at all. This is particularly
noticeable with Wet Brass in Raspberry Jam where there are very short
stabbing chords.
I'll do some more testing hopefully tomorrow, but I must say it is
looking very promising indeed.
P.S.
Overdrive sounds really good :)
--
Will J Godfrey
http://www.musically.me.uk
16 Sep
16 Sep
4:09 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
Well I don't know if this was intended, but
it's arrived in Linux
Audio, not Zyn!
yeah, but I sent to both.
Anyway, progress report :)
First stab at ccmake . gave the error 'Empty cache', but when I did a
plain cmake . by mistake, the repeated ccmake . lo and behold editable
fields magically appeared.
Anothe run as cmake . told my that 'unset' in CMakeLists.txt was not
recognised, so I commented out the three lines from No. 63.
After that I got the complaint that also was not there - well it damn
well is :) The script was being too optimistic. The alsa version I'm
running is 1.0.16 and changing the script to accept that seems to work.
hmmm, I keep forgetting, not everyone runs debian testing :-(.
Initial results running the synth are very good
indeed. However there
is a problem with reverb -> initial delay. It always comes up at 40,
and changing the control has no effect at all. This is particularly
noticeable with Wet Brass in Raspberry Jam where there are very short
stabbing chords.
Yep, interesting. So far I haven't figured it out, but I will.
I'll do some more testing hopefully tomorrow, but
I must say it is
looking very promising indeed.
P.S.
Overdrive sounds really good :)
Ah yes, indeed it does! I've been having some serious fun with Overdrive!
An outstanding patch, and nice to have the machinery do it justice.
Over the next day or so I'll trim back cmake's version demands and
expectations, and hopefully fix Wet Brass, then post another update.
Thank you all for your help.
cheers, Cal
3:29 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
cal wrote:
Folderol wrote:
Mmh Whenever I choose a new instrument bank, it get disconnected with
Jack :(
\r
Well I don't know if this was intended, but
it's arrived in Linux
Audio, not Zyn!
yeah, but I sent to both.
Anyway, progress report :)
First stab at ccmake . gave the error 'Empty cache', but when I did a
plain cmake . by mistake, the repeated ccmake . lo and behold editable
fields magically appeared.
Anothe run as cmake . told my that 'unset' in CMakeLists.txt was not
recognised, so I commented out the three lines from No. 63.
After that I got the complaint that also was not there - well it damn
well is :) The script was being too optimistic. The alsa version I'm
running is 1.0.16 and changing the script to accept that seems to work.
hmmm, I keep forgetting, not everyone runs debian testing :-(.
Initial results running the synth are very good
indeed. However there
is a problem with reverb -> initial delay. It always comes up at 40,
and changing the control has no effect at all. This is particularly
noticeable with Wet Brass in Raspberry Jam where there are very short
stabbing chords.
Yep, interesting. So far I haven't figured it out, but I will.
I'll do some more testing hopefully tomorrow,
but I must say it is
looking very promising indeed.
P.S.
Overdrive sounds really good :)
Ah yes, indeed it does! I've been having some serious fun with Overdrive!
An outstanding patch, and nice to have the machinery do it justice.
Over the next day or so I'll trim back cmake's version demands and
expectations, and hopefully fix Wet Brass, then post another update.
Thank you all for your help.
7:04 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Thu, 17 Sep 2009 04:54:57 +1000
cal <cal(a)graggrag.com> wrote:
Grammostola Rosea wrote:
I used to have this issue but it seems fixed with 2.4.0, so it's
strange that you experience it with yoshimi I think.
Philipp
Mmh Whenever I choose a new instrument bank, it
get disconnected
with Jack :(
That's sad. I'm not seeing that behaviour, but I will go looking.
cheers.
6:56 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Grammostola Rosea wrote:
[ ... ]
Mmh Whenever I choose a new instrument bank, it get disconnected with
Jack :(
Crossed fingers ... in update 0.009 I fixed a couple of string faux pas in the
instrument bank author/comments handling. If I'm real lucky, that might resolve
this issue for you.
cheers.
7:41 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
cal wrote:
Grammostola Rosea wrote:
I'll try it
Is there also a git or svn version?
\r
[ ... ]
Mmh Whenever I choose a new instrument bank, it get disconnected with
Jack :(
Crossed fingers ... in update 0.009 I fixed a couple of string faux pas in the
instrument bank author/comments handling. If I'm real lucky, that might resolve
this issue for you.
7:45 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Grammostola Rosea wrote:
cal wrote:
btw ccmake .
doesn't work here
Grammostola Rosea wrote:
I'll try it
Is there also a git or svn version?
[ ... ]
Mmh Whenever I choose a new instrument bank, it get disconnected with
Jack :(
Crossed fingers ... in update 0.009 I fixed a couple of string faux pas in
the
instrument bank author/comments handling. If I'm real lucky, that might resolve
this issue for you.
7:56 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Grammostola Rosea wrote:
Grammostola Rosea wrote:
It also zombifies when just playing... also with 0.009
\r
cal wrote:
btw ccmake .
doesn't work here
Grammostola Rosea wrote:
I'll try it
Is there also a git or svn version?
[ ... ]
Mmh Whenever I choose a new instrument bank, it get disconnected with
Jack :(
Crossed fingers ... in update 0.009 I fixed a couple of string faux pas
in the
instrument bank author/comments handling. If I'm real lucky, that might resolve
this issue for you.
8:05 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Grammostola Rosea wrote:
Grammostola Rosea wrote:
[OT] And I wasn't able to download the 'normal' zynaddsubfx from git
git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx
Initialized empty Git repository in /home/d/4home/svn/zynaddsubfx/.git/
fatal: The remote end hung up unexpectedly
Grammostola Rosea wrote:
It also zombifies when just playing... also with 0.009
cal wrote:
btw ccmake .
doesn't work here
Grammostola Rosea wrote:
> [ ... ]
>
> Mmh Whenever I choose a new instrument bank, it get disconnected with
> Jack :(
>
>
>
>
Crossed fingers ... in update 0.009 I fixed a couple of string faux pas in the
instrument bank author/comments handling. If I'm real lucky, that might resolve
this issue for you.
I'll try it
Is there also a git or svn version?
11:06 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Grammostola Rosea wrote:
>>> Is there also a git or svn version?
nope, no public repository.
>> btw ccmake .
>>
>> doesn't work here
Oh? How so?
> It also zombifies when just playing... also with
0.009
You seem to be somewhat alone with this one. No offence, but it does
sort of hint that your system setup might be less than ideal. With a
little more info, some help/assistance might be possible.
[OT] And I wasn't able to download the
'normal' zynaddsubfx from git
git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx
Initialized empty Git repository in /home/d/4home/svn/zynaddsubfx/.git/
fatal: The remote end hung up unexpectedly
Can't help with this one, though it's not all that unusual with sourceforge.
The usual solution is to wait a minute/hour/day/week and try again.
cheers, Cal
17 Sep
17 Sep
6:15 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
cal wrote:
Grammostola Rosea wrote:
I think my system is
configured pretty well. I have no problems with any
other audio app.
I use Debian testing
Regards,
\r
>>> Is there also a git or svn version?
nope, no public repository.
>> btw ccmake .
>>
>> doesn't work here
Oh? How so?
> It also zombifies when just playing... also
with 0.009
You seem to be somewhat alone with this one. No offence, but it does
sort of hint that your system setup might be less than ideal. With a
little more info, some help/assistance might be possible.
6:37 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Grammostola Rosea wrote:
cal wrote:
ah, I was waiting to hear that.
Grammostola Rosea wrote:
I think my system is
configured pretty well. I have no problems with any
other audio app. >>> Is there also a git or svn version?
nope, no public repository.
>> btw ccmake .
>>
>> doesn't work here
Oh? How so?
> It also zombifies when just playing... also
with 0.009
You seem to be somewhat alone with this one. No offence, but it does
sort of hint that your system setup might be less than ideal. With a
little more info, some help/assistance might be possible. I use Debian testing
so do I, so ... 64 or 32
bit (or both?)
cheers.
9:30 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Thu, 17 Sep 2009, Grammostola Rosea wrote:
When I was tracing 'zombification' issues in Hydrogen, it was very helpful
to me (the developer) to know:
* jackd settings when firing up the application
(e.g. jackd -R -d alsa -p 4 -n 2 -r 192000 -Xseq)
* A little more about the system (memory, CPU,
distro, jackd version)
* Any command-line options you used to start
the application and cause the fault.
Obviously, Zombies happen more often with aggressive JACK settings.
On the other hand, even with that info it is generally hard to trace out a
Zombification issue. The zombie notification happens a few milliseconds
_after_ the event that waited -- so, backtraces weren't very helpful.
Increasing your logging can corrupt your measurements because I/O is one
source of a zombie. It was even possible, for instance, for one
application to take just a little too long (leaving no time for the 2nd
app). JACK would then blame the zombification on the 2nd app.
I ended up having to do a static code analysis to search for memory
allocation, re-do our logging scheme (because its mutex was causing
locks), and discover some new taboo functions. The biggest surprise (for
me) is that Qt's QString constructor and operator= could not be used in
real-time code.
HTH,
Gabriel
You seem to be
somewhat alone with this one. No offence, but it does
sort of hint that your system setup might be less than ideal. With a
little more info, some help/assistance might be possible.
I think my system is
configured pretty well. I have no problems with any
other audio app.
9:48 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Gabriel M. Beddingfield wrote:
On Thu, 17 Sep 2009, Grammostola Rosea wrote:
When I was tracing 'zombification' issues in Hydrogen, it was very
helpful to me (the developer) to know:
* jackd settings when firing up the application
(e.g. jackd -R -d alsa -p 4 -n 2 -r 192000 -Xseq)
* A little more about the system (memory, CPU,
distro, jackd version)
* Any command-line options you used to start
the application and cause the fault.
Obviously, Zombies happen more often with aggressive JACK settings.
On the other hand, even with that info it is generally hard to trace
out a Zombification issue. The zombie notification happens a few
milliseconds _after_ the event that waited -- so, backtraces weren't
very helpful. Increasing your logging can corrupt your measurements
because I/O is one source of a zombie. It was even possible, for
instance, for one application to take just a little too long (leaving
no time for the 2nd app). JACK would then blame the zombification on
the 2nd app.
I ended up having to do a static code analysis to search for memory
allocation, re-do our logging scheme (because its mutex was causing
locks), and discover some new taboo functions. The biggest surprise
(for me) is that Qt's QString constructor and operator= could not be
used in real-time code.
/usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p128 -n2 -Xseq -zt
jackd (0.116.2+svn3592-3)
Debian testing, Pentium 4 32bit
The only strange thing on my system
This is in my /etc/security/limits.conf
@audio - rtprio 99
@audio - nice -10
@audio - memlock 970215
But ulimit -l
give unlimited
I tried to figure out how come on #jack, but no solution yet
But afaik Zyn should also run properly with unlimited...
\r
You seem
to be somewhat alone with this one. No offence, but it does
sort of hint that your system setup might be less than ideal. With a
little more info, some help/assistance might be possible.
I think my system is
configured pretty well. I have no problems with any
other audio app.
10:03 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
rosea grammostola wrote:
Gabriel M. Beddingfield wrote:
The 'normal' zyn in debian testing 2.4 works a lot better all though it
zombifies too sometimes after a while. (that's why I always use the one
from git, but that's offline now at the moment)
\r
On Thu, 17 Sep 2009, Grammostola Rosea wrote:
When I was tracing 'zombification' issues in Hydrogen, it was very
helpful to me (the developer) to know:
* jackd settings when firing up the application
(e.g. jackd -R -d alsa -p 4 -n 2 -r 192000 -Xseq)
* A little more about the system (memory, CPU,
distro, jackd version)
* Any command-line options you used to start
the application and cause the fault.
Obviously, Zombies happen more often with aggressive JACK settings.
On the other hand, even with that info it is generally hard to trace
out a Zombification issue. The zombie notification happens a few
milliseconds _after_ the event that waited -- so, backtraces weren't
very helpful. Increasing your logging can corrupt your measurements
because I/O is one source of a zombie. It was even possible, for
instance, for one application to take just a little too long (leaving
no time for the 2nd app). JACK would then blame the zombification on
the 2nd app.
I ended up having to do a static code analysis to search for memory
allocation, re-do our logging scheme (because its mutex was causing
locks), and discover some new taboo functions. The biggest surprise
(for me) is that Qt's QString constructor and operator= could not be
used in real-time code.
/usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p128 -n2 -Xseq -zt
jackd (0.116.2+svn3592-3)
Debian testing, Pentium 4 32bit
The only strange thing on my system
This is in my /etc/security/limits.conf
@audio - rtprio 99
@audio - nice -10
@audio - memlock 970215
But ulimit -l
give unlimited
I tried to figure out how come on #jack, but no solution yet
But afaik Zyn should also run properly with unlimited...
\r
You seem
to be somewhat alone with this one. No offence, but it does
sort of hint that your system setup might be less than ideal. With a
little more info, some help/assistance might be possible.
I think my system is
configured pretty well. I have no problems with
any
other audio app.
10:23 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Thu, 17 Sep 2009, rosea grammostola wrote:
The 'normal' zyn in debian testing 2.4 works a
lot better all though it
zombifies too sometimes after a while. (that's why I always use the one
from git, but that's offline now at the moment)
The SF site? I just cloned it last night (even after you had a problem).
I also just did a fetch without a problem.
-gabriel
10:30 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Gabriel M. Beddingfield wrote:
On Thu, 17 Sep 2009, rosea grammostola wrote:
Hmm
$ git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx
Initialized empty Git repository in /home/d/4home/svn/zyn/zynaddsubfx/.git/
fatal: The remote end hung up unexpectedly
The 'normal' zyn in debian testing 2.4
works a lot better all though it
zombifies too sometimes after a while. (that's why I always use the one
from git, but that's offline now at the moment)
The SF site? I just cloned it last night (even after you had a
problem). I also just did a fetch without a problem.
11:58 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Thu, 17 Sep 2009, rosea grammostola wrote:
Gabriel M. Beddingfield wrote:
Should be:
$ git clone \
git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx/zynaddsubfx
HTH,
Gabriel
On Thu, 17 Sep 2009, rosea grammostola wrote:
Hmm
$ git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx The 'normal' zyn in debian testing 2.4
works a lot better all though it
zombifies too sometimes after a while. (that's why I always use the one
from git, but that's offline now at the moment)
The SF site? I just cloned it last night (even after you had a
problem). I also just did a fetch without a problem.
12:18 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Gabriel M. Beddingfield wrote:
On Thu, 17 Sep 2009, rosea grammostola wrote:
[OT]
Thanks
But it doesn't run
ZynAddSubFX - Copyright (c) 2002-2009 Nasca Octavian Paul and others
Compiled: Sep 17 2009 16:09:52
This program is free software (GNU GPL v.2 or later) and
it comes with ABSOLUTELY NO WARRANTY.
Try 'zynaddsubfx --help' for command-line options.
Sample Rate = 44100
Sound Buffer Size = 128 samples
Internal latency = 2.9 ms
ADsynth Oscil.Size = 65536 samples
ERROR - I can't open the .
And then it hangs, system gets very slow and zyn doesn't show up totally
[/OT]
\r
Gabriel M. Beddingfield wrote:
Should be:
$ git clone \
git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx/zynaddsubfx
On Thu, 17 Sep 2009, rosea grammostola wrote:
Hmm
$ git clone git://zynaddsubfx.git.sourceforge.net/gitroot/zynaddsubfx The 'normal' zyn in debian testing 2.4
works a lot better all
though it
zombifies too sometimes after a while. (that's why I always use the
one
from git, but that's offline now at the moment)
The SF site? I just cloned it last night (even after you had a
problem). I also just did a fetch without a problem.
12:27 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Thu, 17 Sep 2009, rosea grammostola wrote:
[OT]
Thanks
But it doesn't run
ZynAddSubFX - Copyright (c) 2002-2009 Nasca Octavian Paul and others
Compiled: Sep 17 2009 16:09:52
This program is free software (GNU GPL v.2 or later) and
it comes with ABSOLUTELY NO WARRANTY.
Try 'zynaddsubfx --help' for command-line options.
Sample Rate = 44100
Sound Buffer Size = 128 samples
Internal latency = 2.9 ms
ADsynth Oscil.Size = 65536 samples
ERROR - I can't open the .
And then it hangs, system gets very slow and zyn doesn't show up totally
[/OT]
Same here. I think it's trying to use OSS. That's when I realized that
cal's yoshimi was a fork. (I wasn't paying close attention before....)
If you free up your audio card (i.e. _don't_ run JACK), Zyn worked fine
for me.
-Gabriel
6:14 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Gabriel M. Beddingfield wrote:
On Thu, 17 Sep 2009, rosea grammostola wrote:
Not for me yet. I run Kde and maybe it has problems using OSS too?
Why doesn't this one work with Jack?
\r
[OT]
Thanks
But it doesn't run
ZynAddSubFX - Copyright (c) 2002-2009 Nasca Octavian Paul and others
Compiled: Sep 17 2009 16:09:52
This program is free software (GNU GPL v.2 or later) and
it comes with ABSOLUTELY NO WARRANTY.
Try 'zynaddsubfx --help' for command-line options.
Sample Rate = 44100
Sound Buffer Size = 128 samples
Internal latency = 2.9 ms
ADsynth Oscil.Size = 65536 samples
ERROR - I can't open the .
And then it hangs, system gets very slow and zyn doesn't show up totally
[/OT]
Same here. I think it's trying to use OSS. That's when I realized
that cal's yoshimi was a fork. (I wasn't paying close attention
before....)
If you free up your audio card (i.e. _don't_ run JACK), Zyn worked
fine for me.
6:21 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Thu, 17 Sep 2009, rosea grammostola wrote:
Not for me yet. I run Kde and maybe it has problems
using OSS too?
Why doesn't this one work with Jack?
The README.txt file says you have to manually edit src/Makefile.inc to
enable support for JACK.
-gabriel
16 Sep
16 Sep
6:39 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
[ ... ]
First stab at ccmake . gave the error 'Empty cache', but when I did a
plain cmake . by mistake, the repeated ccmake . lo and behold editable
fields magically appeared.
Anothe run as cmake . told my that 'unset' in CMakeLists.txt was not
recognised, so I commented out the three lines from No. 63.
After that I got the complaint that also was not there - well it damn
well is :) The script was being too optimistic. The alsa version I'm
running is 1.0.16 and changing the script to accept that seems to work.
Initial results running the synth are very good indeed. However there
is a problem with reverb -> initial delay. It always comes up at 40,
and changing the control has no effect at all. This is particularly
noticeable with Wet Brass in Raspberry Jam where there are very short
stabbing chords.
I'll do some more testing hopefully tomorrow, but I must say it is
looking very promising indeed.
Fixed reverb initial delay & friends, hopefully made the cmake build more
accommodating, and sorted a couple of untidy string transgressions.
Update 0.009, <http://www.graggrag.com/?q=node/19>
cheers.
17 Sep
17 Sep
7:40 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Thu, 17 Sep 2009 06:38:43 +1000
cal <cal(a)graggrag.com> wrote:
Folderol wrote:
Well I gave this one my best shot - spent all evening trying to compile
it but had to give up in the end. It complains that there is no fltk -
fluid executable. Well, there is exactly the same one that v 0.008
compiled with :(
This time I couldn't even work out where to fudge around in the
scripts to try to force it to work :((
--
Will J Godfrey
http://www.musically.me.uk
[ ... ]
First stab at ccmake . gave the error 'Empty cache', but when I did a
plain cmake . by mistake, the repeated ccmake . lo and behold editable
fields magically appeared.
Anothe run as cmake . told my that 'unset' in CMakeLists.txt was not
recognised, so I commented out the three lines from No. 63.
After that I got the complaint that also was not there - well it damn
well is :) The script was being too optimistic. The alsa version I'm
running is 1.0.16 and changing the script to accept that seems to work.
Initial results running the synth are very good indeed. However there
is a problem with reverb -> initial delay. It always comes up at 40,
and changing the control has no effect at all. This is particularly
noticeable with Wet Brass in Raspberry Jam where there are very short
stabbing chords.
I'll do some more testing hopefully tomorrow, but I must say it is
looking very promising indeed.
Fixed reverb initial delay & friends, hopefully made the cmake build more
accommodating, and sorted a couple of untidy string transgressions.
Update 0.009, <http://www.graggrag.com/?q=node/19>
cheers.
18 Sep
18 Sep
9:18 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
On Thu, 17 Sep 2009 06:38:43 +1000
cal <cal(a)graggrag.com> wrote:
> Update 0.009,
<http://www.graggrag.com/?q=node/19>
Well I gave this one my best shot - spent all evening
trying to compile
it but had to give up in the end. It complains that there is no fltk -
fluid executable. Well, there is exactly the same one that v 0.008
compiled with :(
This time I couldn't even work out where to fudge around in the
scripts to try to force it to work :((
Hmmm, sorry about that, my bad, and a big one. Let us never speak of this again!
And so there's 0.010, <http://www.graggrag.com/zyn/yoshimi-0.010.tar.bz2>.
I've tested it with an older version of cmake, so hopefully the lack of
'unset' nonsense is over.
cheers, Cal
5:41 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Fri, 18 Sep 2009 21:18:38 +1000
cal <cal(a)graggrag.com> wrote:
And so there's 0.010,
<http://www.graggrag.com/zyn/yoshimi-0.010.tar.bz2>.
I've tested it with an older version of cmake, so hopefully the lack of
'unset' nonsense is over.
cheers, Cal
OK, just given this some torture testing and it is coming out very, very
well :)
The best bit was running 'Lair Of The Dragon King' and recording it via
TimeMachine, while at the same time playing along to it with my MIDI
keyboard using the Hyper Matrix patch. Processors peaking at around 70%
but not a single pffuzz burble or click :D
All the other tunes ran fine and sounded correct.
I was able to change voice patches while running, there were clicks
sometimes - especially when loading the more complex ones, but I'm not
at all surprised by that. There were no zombies of major screw-ups.
I was also able to silently open the virtual keyboard and use both the
mouse pointer and the computer keyboard to play along, without any
noticeable problems.
I should also add, I was reloading parameter sets without quitting
yoshimi at all. With zyn 2.2.1 this is a guaranteed way to get zombies.
Minor quibbles:
It seems ccmake can't run without a default cache script. I have to run
cmake first then go back to ccmake, then cmake again.
I'd removed a dev package (no I don't know why either) and it reported
a missing package but didn't say which one it was! That was fun for a
while :)
On the main display, the instrument name is above the box, not in it.
P.S.
I would really, really like direct recording back.
... please
... pretty please :)
--
Will J Godfrey
http://www.musically.me.uk
5:48 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
On Fri, 18 Sep 2009 21:18:38 +1000
cal <cal(a)graggrag.com> wrote:
Strange... that it works so badly here. It must be cursed... When I
reach my mouse to it, it almost start to cry and zombify directly...
\r
And so there's 0.010,
<http://www.graggrag.com/zyn/yoshimi-0.010.tar.bz2>.
I've tested it with an older version of cmake, so hopefully the lack of
'unset' nonsense is over.
cheers, Cal
OK, just given this some torture testing and it is coming out very, very
well :)
The best bit was running 'Lair Of The Dragon King' and recording it via
TimeMachine, while at the same time playing along to it with my MIDI
keyboard using the Hyper Matrix patch. Processors peaking at around 70%
but not a single pffuzz burble or click :D
All the other tunes ran fine and sounded correct.
I was able to change voice patches while running, there were clicks
sometimes - especially when loading the more complex ones, but I'm not
at all surprised by that. There were no zombies of major screw-ups.
I was also able to silently open the virtual keyboard and use both the
mouse pointer and the computer keyboard to play along, without any
noticeable problems.
I should also add, I was reloading parameter sets without quitting
yoshimi at all. With zyn 2.2.1 this is a guaranteed way to get zombies.
Minor quibbles:
It seems ccmake can't run without a default cache script. I have to run
cmake first then go back to ccmake, then cmake again.
I'd removed a dev package (no I don't know why either) and it reported
a missing package but didn't say which one it was! That was fun for a
while :)
On the main display, the instrument name is above the box, not in it.
P.S.
I would really, really like direct recording back.
... please
... pretty please :)
6:07 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Fri, 18 Sep 2009 21:46:51 +0200
rosea grammostola <rosea.grammostola(a)gmail.com> wrote:
Strange... that it works so badly here. It must be
cursed... When I
reach my mouse to it, it almost start to cry and zombify directly...
\r
Maybe you're using a Microsoft mouse :)
Seriously...
I wonder if it's something to do with your version of jack. I've heard
that jack-2 has some issues, and if you're running debian testing I
think that's what you'll have. I'm running the older jack version.
My build is 64studio 3.0 beta, which is based on ubuntu 8.10. I've
added some debian lenny overlays to get newer versions of
build-essential, cmake etc.
--
Will J Godfrey
http://www.musically.me.uk
6:39 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Fri, 18 Sep 2009, rosea grammostola wrote:
Strange... that it works so badly here. It must be
cursed... When I
reach my mouse to it, it almost start to cry and zombify directly...
Are you building Zyn from the sourceforge site?
Or are you building yoshimi from cal's tarball?
They're not the same, and I think Folderol is talking about yoshimi.
HTH,
Gabriel
6:48 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Gabriel M. Beddingfield wrote:
On Fri, 18 Sep 2009, rosea grammostola wrote:
I talk
about yoshimi too.
(All though Zyn from git isn't perfect too, pops and clicks and some
zombifying... sad that such a synth works pretty bad... Such a synth
should work properly with jack, also realtime! I understand that this
thread is about improving it. I hope more people will understand that a
good Zyn with jack is good for linuxaudio and a bad one bad...)
Strange... that it works so badly here. It must
be cursed... When I
reach my mouse to it, it almost start to cry and zombify directly...
Are you building Zyn from the sourceforge site?
Or are you building yoshimi from cal's tarball?
They're not the same, and I think Folderol is talking about yoshimi.
8:13 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
rosea grammostola wrote:
[ ... ]
(All though Zyn from git isn't perfect too, pops and clicks and some
zombifying... sad that such a synth works pretty bad... Such a synth
should work properly with jack, also realtime! I understand that this
thread is about improving it. I hope more people will understand that a
good Zyn with jack is good for linuxaudio and a bad one bad...)
... which is precisely what led me to look at the zyn code in the first
place. Jack io is fairly well understood these days (very different to
2002-2005 when ZynAddSubFX was written!) so I figured it had to be
possible for it to work well. That said, it wasn't exactly a simple task
to get it to where it is now - major restructuring required.
I noticed earlier that you're running with a jack period size 128. For my
benefit in seeking robustness, does yoshimi behave any better for you with
a period size of 256?
cheers.
8:58 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
cal wrote:
rosea grammostola wrote:
Yes great job. You should also ask some help on the lad or jack mailinglist
[ ... ]
(All though Zyn from git isn't perfect too, pops and clicks and some
zombifying... sad that such a synth works pretty bad... Such a synth
should work properly with jack, also realtime! I understand that this
thread is about improving it. I hope more people will understand that a
good Zyn with jack is good for linuxaudio and a bad one bad...)
... which is precisely what led me to look at the zyn code in the first
place. Jack io is fairly well understood these days (very different to
2002-2005 when ZynAddSubFX was written!) so I figured it had to be
possible for it to work well. That said, it wasn't exactly a simple task
to get it to where it is now - major restructuring required.
I noticed earlier that you're running with a jack
period size 128. For my
benefit in seeking robustness, does yoshimi behave any better for you with
a period size of 256?
Yes > 256 improves playing, but choosing a new instrument bank zombifies
yoshi directly
9:22 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Saturday 19 of September 2009 00:57:04 rosea grammostola wrote:
No zombies here, but I get xruns almost every time I switch instruments
in yoshimi.
Of course that's not nearly as bad as zombified clients, but at least it
indicates that something about yoshimi's realtime behaviour is still not
quite right (although it behaves much better than zynaddsubfx).
What's your Jack client timeout (jackd -t, default is 500ms)? What
happens if you increase it? What if you add -Z to your Jack command
line?
Dominic
I noticed
earlier that you're running with a jack period size 128.
For my benefit in seeking robustness, does yoshimi behave any
better for you with a period size of 256?
Yes > 256 improves playing, but choosing a new instrument bank
zombifies yoshi directly
19 Sep
19 Sep
7:39 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Sat, 19 Sep 2009 01:21:08 +0200
Dominic Sacré <dominic.sacre(a)gmx.de> wrote:
On Saturday 19 of September 2009 00:57:04 rosea
grammostola wrote:
No zombies here, but I get xruns almost every time I switch
instruments in yoshimi.
Of course that's not nearly as bad as zombified clients, but at least
it indicates that something about yoshimi's realtime behaviour is
still not quite right (although it behaves much better than
zynaddsubfx).
What's your Jack client timeout (jackd -t, default is 500ms)? What
happens if you increase it? What if you add -Z to your Jack command
line?
Dominic
I think I mentioned it before, but I used to get zombies all the time
when switching instruments, now with 2.4.0 (the thing yoshimi is
apparently based on) I don't get them anymore but you guys get them
with yoshimi?
I'm running jack without any -t setting, don't know what it defaults to
then, 500ms?
Philipp
I noticed
earlier that you're running with a jack period size 128.
For my benefit in seeking robustness, does yoshimi behave any
better for you with a period size of 256?
Yes > 256 improves playing, but choosing a new instrument bank
zombifies yoshi directly 
18 Sep
18 Sep
9:32 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Sat, Sep 19, 2009 at 08:13:29AM +1000, cal wrote:
... which is precisely what led me to look at the zyn
code in the first
place. Jack io is fairly well understood these days (very different to
2002-2005 when ZynAddSubFX was written!) so I figured it had to be
possible for it to work well. That said, it wasn't exactly a simple task
to get it to where it is now - major restructuring required.
I noticed earlier that you're running with a jack period size 128. For my
benefit in seeking robustness, does yoshimi behave any better for you with
a period size of 256?
Here the build fails at the linking stage with undefined refs to
gzopen & co. I do have gzip and devel files installed.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
10:27 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Fons Adriaensen wrote:
[ ... ]
Here the build fails at the linking stage with
undefined refs to
gzopen & co. I do have gzip and devel files installed.
Very interesting. Now that you bring it up I can't quite see how it manages
to link on my system (debian). I'll have to think about that one.
cheers.
19 Sep
19 Sep
7:43 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Fons Adriaensen wrote:
Here the build fails at the linking stage with
undefined refs to
gzopen & co. I do have gzip and devel files installed.
I still don't see how it manages to link (for some) as is, so I've added
a check for libz to CMakeLists.txt, which then explicitly adds libz to the
link mix. Hopefully that'll fix it for you, but I can't really tell.
From Will J Godfrey's list of quirks, I think
I've fixed
- silent failure when a couple of required resources weren't
found
- the wandering instrument name on main panel
And so there was 0.011, <http://www.graggrag.com/zyn/yoshimi-0.011.tar.bz2>
I believe there's a couple of remaining quirks related to a very tentative
attempt to replace some of the multitude of char [] allocations with
std::string, eg part name and friends. I figure it'll come down to either
fixing those and taking that effort further, or simply reverting to the
original (and reasonably well behaving) form. Advice anyone?
cheers, Cal
8:30 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
cal wrote:
And so there was 0.011,
<http://www.graggrag.com/zyn/yoshimi-0.011.tar.bz2>
I'm joining a bit late, sorry about that.
A question: what's the relationship between yoshimi and zynaddsubfx? Is
yoshimi a fork by cal? Are there any plans to merge the changes back or
are you (cal) prepared to carry the project alone?
Now to my problems: I'm on arch linux and "ccmake ." enters an
interactive shell (it shouldn't, should it?) and pressing "g" for
generate produced the following errors:
CMake Error at CMakeLists.txt:273 (add_executable):
Target "yoshimi" links to item " fltk" which has leading or
trailing
whitespace. This is now an error according to policy CMP0004.
CMake Error at CMakeLists.txt:273 (add_executable):
Target "yoshimi" links to item " Xft" which has leading or
trailing
whitespace. This is now an error according to policy CMP0004.
CMake Error at CMakeLists.txt:273 (add_executable):
Target "yoshimi" links to item " pthread" which has leading or
trailing
whitespace. This is now an error according to policy CMP0004.
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
9:12 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Atte Andre Jensen wrote:
I'm joining a bit late, sorry about that.
welcome to the party.
A question: what's the relationship between
yoshimi and zynaddsubfx? Is
yoshimi a fork by cal?
Not exactly a fork, no, I've never had that intention.
I've loved ZynAddSubFX
since it first appeared, but lately found increasing frustration at a) the
crackling, and b) the official project showed no signs of addressing the real
performance issues. So I started futzing about with the code, and eventually
got it to where it is now.
Are there any plans to merge the changes back
I
hope so, but I wouldn't bet on it happening soon. There's a bit of history
there, see the ZynAddSubFX user list archive to catch up.
are you (cal) prepared to carry the project alone?
Sigh. Sooner or later I'll have to explain this, so it might as well be now.
I'm dealing with a healthy dose of cancer, currently in week 5 of 6 of a
radiotherapy binge, toasting tumors! My sporadic bursts of genuine productivity
are all too short and too far apart. Sorry, but I'm in no position to take on
a major role in either sorting out the real ZynAddSubFX, or in carrying a fork.
As the web page says, I've presented a development snapshot that at the very
least demonstrates that functional jack io _is_ possible with ZynAddSubFX, plus
an example of how it might be done. I have no doubt that others more skilled
than me could do it better. I'd be happy to help with sorting out the official
codebase, but I think there'll need to be a slight attitudinal adjustment before
that can happen.
Now to my problems: I'm on arch linux and
"ccmake ." enters an
interactive shell (it shouldn't, should it?) and pressing "g" for
generate produced the following errors:
CMake Error at CMakeLists.txt:273 (add_executable):
Target "yoshimi" links to item " fltk" which has leading or
trailing
whitespace. This is now an error according to policy CMP0004.
CMake Error at CMakeLists.txt:273 (add_executable):
Target "yoshimi" links to item " Xft" which has leading or
trailing
whitespace. This is now an error according to policy CMP0004.
CMake Error at CMakeLists.txt:273 (add_executable):
Target "yoshimi" links to item " pthread" which has leading or
trailing
whitespace. This is now an error according to policy CMP0004.
At a guess, a policy adjustment might be the best way to resolve this. For that
I'll need to do some reading first (or you could!). What does your
'cmake --version' report?
cheers, Cal
10:12 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
cal wrote:
I'm really, really sorry to hear that. I don't know what to say...
I hope the treatment goes well, and you can regain you health.
The only thing I can offer is prayer, just say "no" if you don't want
that for some reason.
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
are you (cal)
prepared to carry the project alone?
Sigh. Sooner or later I'll have to explain
this, so it might as well be now.
I'm dealing with a healthy dose of cancer, currently in week 5 of 6 of a
radiotherapy binge, toasting tumors! 
9:43 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Hi Cal,
All the best with the radiotherapy, and big thanks for finding time to do a little work on
Linux audio stuff!
My Dad is about 3-4 weeks into his toasting for prostate cancer. He's doing well and I
hope you are too!
Best wishes
Norv
__________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/
9:34 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Atte Andre Jensen wrote:
[ ... ]
Target "yoshimi" links to item "
fltk" which has leading or trailing
whitespace. This is now an error according to policy CMP0004.
Could you maybe try this and let me know the result?
{{{
--- yoshimi-dev.orig/src/CMakeLists.txt
+++ yoshimi-dev/src/CMakeLists.txt
@@ -16,7 +16,7 @@
project(Yoshimi)
cmake_minimum_required(VERSION 2.6)
-cmake_policy(VERSION 2.6)
+cmake_policy(VERSION 2.6 OLD)
set(YOSHIMI_VERSION "0.011")
FILE(WRITE version.txt "${YOSHIMI_VERSION}")
}}}
9:47 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Atte Andre Jensen wrote:
CMake Error at CMakeLists.txt:273 (add_executable):
Target "yoshimi" links to item " fltk" which has leading or
trailing
whitespace. This is now an error according to policy CMP0004.
perhaps this?
{{{
--- yoshimi-dev.orig/src/CMakeLists.txt
+++ yoshimi-dev/src/CMakeLists.txt
@@ -17,6 +17,7 @@
project(Yoshimi)
cmake_minimum_required(VERSION 2.6)
cmake_policy(VERSION 2.6)
+cmake_policy(SET CMP0004 OLD)
set(YOSHIMI_VERSION "0.011")
FILE(WRITE version.txt "${YOSHIMI_VERSION}")
}}}
10:13 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
cal wrote:
perhaps this?
{{{
--- yoshimi-dev.orig/src/CMakeLists.txt
+++ yoshimi-dev/src/CMakeLists.txt
@@ -17,6 +17,7 @@
project(Yoshimi)
cmake_minimum_required(VERSION 2.6)
cmake_policy(VERSION 2.6)
+cmake_policy(SET CMP0004 OLD)
set(YOSHIMI_VERSION "0.011")
FILE(WRITE version.txt "${YOSHIMI_VERSION}")
}}}
That works, thanks!
Must test the thingy later, but now it builds and runs :-)
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
4:28 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Sat, 19 Sep 2009 19:42:54 +1000
cal <cal(a)graggrag.com> wrote:
Fons Adriaensen wrote:
Haven't had the chance to try this version yet, but have been doing a
lot of work with 0.010
I can confirm that both the addsynth and subsynth parameter controls
seem to be working fine at quite a deep level, also effects reverb,
chorus, phaser & distortion are responding as I'd expect.
... and I've now created a few new voice patches :)
I must put them up sometime.
--
Will J Godfrey
http://www.musically.me.uk
Here the build fails at the linking stage with
undefined refs to
gzopen & co. I do have gzip and devel files installed.
I still don't see how it manages to link (for some) as is, so I've added
a check for libz to CMakeLists.txt, which then explicitly adds libz to the
link mix. Hopefully that'll fix it for you, but I can't really tell.
From Will J Godfrey's list of quirks, I think I've fixed
- silent failure when a couple of required resources weren't found
- the wandering instrument name on main panel
And so there was 0.011, <http://www.graggrag.com/zyn/yoshimi-0.011.tar.bz2>
I believe there's a couple of remaining quirks related to a very tentative
attempt to replace some of the multitude of char [] allocations with
std::string, eg part name and friends. I figure it'll come down to either
fixing those and taking that effort further, or simply reverting to the
original (and reasonably well behaving) form. Advice anyone?
cheers, Cal
4:35 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
[ ... ]
Haven't had the chance to try this version yet, but have been doing a
lot of work with 0.010
there's really only build fixes through to 0.012.
I can confirm that both the addsynth and subsynth
parameter controls
seem to be working fine at quite a deep level, also effects reverb,
chorus, phaser & distortion are responding as I'd expect.
... and I've now created a few new voice patches :)
I must put them up sometime.
cool, look forward to seeing them!
I've started looking at the record function, and it's a bit frightening,
but I'll see where it takes me.
cheers.
9:52 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Sun, 20 Sep 2009 04:35:04 +1000
cal <cal(a)graggrag.com> wrote:
Folderol wrote:
Some more info.
Yoshimi has now run continuously for about 20 hours. In that time I've
been loading and saving entire parameter sets, editing patches and
saving them, both with and without Rosegarden triggering notes. There
hasn't been a single freeze!
If there is no sound being produced, then patches load and save
silently, although there are xruns showing in jack's message window. If
Yoshimi is actually producing sound then there are usually clicks as the
patches are changed, regardless of whether that particular channel is
sounding. The amount of sound disturbance seems quite closely linked to
the patch size/complexity.
I deliberately overloaded it by getting Rosegarden to send a fairly
fast pattern of notes to the Hyper Matrix patch. The processors maxed
out sounding rather unpleasant for a second, then it was Rosegarden that
just stopped dead complaining of no CPU room. Changed channel on
Rosegarden (so as not to actually disturb Yoshimi's state) to play a
less demanding patch and everything was fine. The Hyper Matrix channel
was still live, as I could play notes from my keyboard via Rosegarden.
I'm not seeing any xruns at all in response to MIDI input of Note
On/Off, Master Volume, Pan, Modulation, Pitch Change.
As far as I'm concerned, we've now reached a level of stability that
makes live performance practical.
--
Will J Godfrey
http://www.musically.me.uk
[ ... ]
Haven't had the chance to try this version yet, but have been doing a
lot of work with 0.010
there's really only build fixes through to 0.012.
I can confirm that both the addsynth and subsynth
parameter controls
seem to be working fine at quite a deep level, also effects reverb,
chorus, phaser & distortion are responding as I'd expect.
... and I've now created a few new voice patches :)
I must put them up sometime.
cool, look forward to seeing them!
I've started looking at the record function, and it's a bit frightening,
but I'll see where it takes me.
cheers.
10:33 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
[...]
Some more info.
Yoshimi has now run continuously for about 20 hours. In that time I've
been loading and saving entire parameter sets, editing patches and
saving them, both with and without Rosegarden triggering notes. There
hasn't been a single freeze!
If there is no sound being produced, then patches load and save
silently, although there are xruns showing in jack's message window. If
Yoshimi is actually producing sound then there are usually clicks as the
patches are changed, regardless of whether that particular channel is
sounding. The amount of sound disturbance seems quite closely linked to
the patch size/complexity.
I deliberately overloaded it by getting Rosegarden to send a fairly
fast pattern of notes to the Hyper Matrix patch. The processors maxed
out sounding rather unpleasant for a second, then it was Rosegarden that
just stopped dead complaining of no CPU room. Changed channel on
Rosegarden (so as not to actually disturb Yoshimi's state) to play a
less demanding patch and everything was fine. The Hyper Matrix channel
was still live, as I could play notes from my keyboard via Rosegarden.
I'm not seeing any xruns at all in response to MIDI input of Note
On/Off, Master Volume, Pan, Modulation, Pitch Change.
As far as I'm concerned, we've now reached a level of stability that
makes live performance practical.
Wow, that is all rather cool. I feel good, I feel better than James Brown.
Like I said previously, the best people to have testing are those who _use_
it extensively. Thanks again for your efforts. On we go!
20 Sep
20 Sep
2:02 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Sat, Sep 19, 2009 at 8:33 PM, cal <cal(a)graggrag.com> wrote:
Wow, that is all rather cool. I feel good, I feel
better than James Brown.
a was not was fan ... that's almost better than you working on zyn
.... worse pay, better hours. worse pay, better fellow workers .. if
you know what i mean :))
--p
3:16 a.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Paul Davis wrote:
On Sat, Sep 19, 2009 at 8:33 PM, cal
<cal(a)graggrag.com> wrote:
Yep, sure do! And you of all people picked it! Why am I not surprised?
Cheers.
Wow, that is all rather cool. I feel good, I feel
better than James Brown.
a was not was fan ... that's almost better than you working on zyn
.... worse pay, better hours. worse pay, better fellow workers .. if
you know what i mean :))
19 Sep
19 Sep
4:58 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
[...]
I can confirm that both the addsynth and subsynth parameter controls
seem to be working fine at quite a deep level, also effects reverb,
chorus, phaser & distortion are responding as I'd expect.
There's something I've wondered about regarding effects volume controls that
you may or may not be able to help me with - as is, if it's an insertion effect,
its volume control is straight linear in effect, while on a non-insertion effect
it's logarithmic. I've wondered whether a log or pseudo-log characteristic on
the insertion effect might yield good things. I'm leaving it alone until I
figure out how, where and why to evaluate the results of such a change though :-).
There's a few potential candidates for such a change, so I'm curious.
cheers.
7:40 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Sun, 20 Sep 2009 04:58:40 +1000
cal <cal(a)graggrag.com> wrote:
Folderol wrote:
Here be dragons!
While I would agree in general that a log scale would be better, both
from a usability point of view, and consistency with the rest, how is
this going to effect existing patches?
I have a *lot* of patches. Apart from Paul's default set, I've gathered
over a hundred from other people as well as creating about the same
number myself - I would be less than delighted if these all started to
misbehave!
I would be happy with apparent log behaviour without changing the
software's interpretation of the actual stored numbers, although this
might give a rather strange 'feel'. It would depend on how fine-grained
the actual numbers were.
The only other practical possibility I can think of would be build
in a parameter file conversion utility (I think this was done in Zyn's
early days) and put an ID tag in new files (this was not done!) so that
appropriate loading behaviour could be done.
To go this way would also need agreement with the main Zyn branch
otherwise we'd end up with two incompatible systems.
All in all, I wonder if it would bring enough benefits to be actually
worth the effort.
--
Will J Godfrey
http://www.musically.me.uk
[...]
I can confirm that both the addsynth and subsynth parameter controls
seem to be working fine at quite a deep level, also effects reverb,
chorus, phaser & distortion are responding as I'd expect.
There's something I've wondered about regarding effects volume controls that
you may or may not be able to help me with - as is, if it's an insertion effect,
its volume control is straight linear in effect, while on a non-insertion effect
it's logarithmic. I've wondered whether a log or pseudo-log characteristic on
the insertion effect might yield good things. I'm leaving it alone until I
figure out how, where and why to evaluate the results of such a change though :-).
There's a few potential candidates for such a change, so I'm curious.
cheers.
9:34 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
[ ... ]
Here be dragons!
While I would agree in general that a log scale would be better, both
from a usability point of view, and consistency with the rest, how is
this going to effect existing patches?
I have a *lot* of patches. Apart from Paul's default set, I've gathered
over a hundred from other people as well as creating about the same
number myself - I would be less than delighted if these all started to
misbehave!
I would be happy with apparent log behaviour without changing the
software's interpretation of the actual stored numbers, although this
might give a rather strange 'feel'. It would depend on how fine-grained
the actual numbers were.
The only other practical possibility I can think of would be build
in a parameter file conversion utility (I think this was done in Zyn's
early days) and put an ID tag in new files (this was not done!) so that
appropriate loading behaviour could be done.
To go this way would also need agreement with the main Zyn branch
otherwise we'd end up with two incompatible systems.
All in all, I wonder if it would bring enough benefits to be actually
worth the effort.
Thanks, I think that closely parallels my own fears, dreads and reservations.
End of story.
cheers,
20 Sep
20 Sep
2:07 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Sun, 20 Sep 2009 09:34:35 +1000
cal <cal(a)graggrag.com> wrote:
Folderol wrote:
It seems that Mark is looking at a similar issue on the main Zyn site.
--
Will J Godfrey
http://www.musically.me.uk
[ ... ]
Here be dragons!
While I would agree in general that a log scale would be better, both
from a usability point of view, and consistency with the rest, how is
this going to effect existing patches?
I have a *lot* of patches. Apart from Paul's default set, I've gathered
over a hundred from other people as well as creating about the same
number myself - I would be less than delighted if these all started to
misbehave!
I would be happy with apparent log behaviour without changing the
software's interpretation of the actual stored numbers, although this
might give a rather strange 'feel'. It would depend on how fine-grained
the actual numbers were.
The only other practical possibility I can think of would be build
in a parameter file conversion utility (I think this was done in Zyn's
early days) and put an ID tag in new files (this was not done!) so that
appropriate loading behaviour could be done.
To go this way would also need agreement with the main Zyn branch
otherwise we'd end up with two incompatible systems.
All in all, I wonder if it would bring enough benefits to be actually
worth the effort.
Thanks, I think that closely parallels my own fears, dreads and reservations.
End of story.
cheers,
11:22 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
Folderol wrote:
[ ... ]
It seems that Mark is looking at a similar issue on the main Zyn site.
yep, I've been following that thread with interest since James Morris
brought it up last week. It was just a subtle point in your previous post
that triggered my direct question here.
cheers, Cal
18 Sep
18 Sep
10:25 p.m.
New subject: [Zynaddsubfx-user] zyn and the art of software maintenance
On Fri, 18 Sep 2009 20:41:27 +0100
Folderol <folderol(a)ukfsn.org> wrote:
On Fri, 18 Sep 2009 21:18:38 +1000
cal <cal(a)graggrag.com> wrote:
Some further stress testing (and I should have gone to bed long ago!)
Plus
I'm really not hearing any problems. I've been editing voices in both
addsynth and subsynth. All controls that I twiddled so far seem to work
correctly. Saving works, and the new versions load and play back in Zyn
the same (as far as I can tell). Not played with padsynth yet, but that
is a bit of a beast.
Minus
When you edit the name of a voice patch, the display doesn't update, but
the saved version is correctly named, and reloading it displays the
right name.
--
Will J Godfrey
http://www.musically.me.uk
And so there's 0.010,
<http://www.graggrag.com/zyn/yoshimi-0.010.tar.bz2>.
I've tested it with an older version of cmake, so hopefully the lack of
'unset' nonsense is over.
cheers, Cal
OK, just given this some torture testing and it is coming out very, very
well :)
The best bit was running 'Lair Of The Dragon King' and recording it via
TimeMachine, while at the same time playing along to it with my MIDI
keyboard using the Hyper Matrix patch. Processors peaking at around 70%
but not a single pffuzz burble or click :D
All the other tunes ran fine and sounded correct.
I was able to change voice patches while running, there were clicks
sometimes - especially when loading the more complex ones, but I'm not
at all surprised by that. There were no zombies of major screw-ups.
I was also able to silently open the virtual keyboard and use both the
mouse pointer and the computer keyboard to play along, without any
noticeable problems.
I should also add, I was reloading parameter sets without quitting
yoshimi at all. With zyn 2.2.1 this is a guaranteed way to get zombies.
Minor quibbles:
It seems ccmake can't run without a default cache script. I have to run
cmake first then go back to ccmake, then cmake again.
I'd removed a dev package (no I don't know why either) and it reported
a missing package but didn't say which one it was! That was fun for a
while :)
On the main display, the instrument name is above the box, not in it.
P.S.
I would really, really like direct recording back.
... please
... pretty please :)
17 Sep
17 Sep
1:36 a.m.
On Tue, Sep 15, 2009 at 6:53 AM, cal <cal(a)graggrag.com> wrote:
Snapshot tarball at
<http://www.graggrag.com/?q=node/19> for those interested.
Hi, and thank you for this wonderful effort!
I am receiving this error when I build:
josh@studiobox:~/src/yoshimi-0.009/src$ make
[ 1%] Building CXX object CMakeFiles/yoshimi.dir/MusicIO/JackEngine.cpp.o
/home/josh/src/yoshimi-0.009/src/MusicIO/JackEngine.cpp: In member
function ‘bool JackEngine::Start()’:
/home/josh/src/yoshimi-0.009/src/MusicIO/JackEngine.cpp:90: error:
‘jack_set_info_function’ was not declared in this scope
make[2]: *** [CMakeFiles/yoshimi.dir/MusicIO/JackEngine.cpp.o] Error 1
make[1]: *** [CMakeFiles/yoshimi.dir/all] Error 2
make: *** [all] Error 2
This might be useful, I am running Debian Lenny:
josh@studiobox:~/src/yoshimi-0.009/src$ jackd -v
jackd 0.109.2
I also have libjack-dev installed. Am I doing something wrong? Any
help would be appreciated, I'm excited about this!
--
Josh Lawrence
http://www.hardbop200.com
2:39 a.m.
Josh Lawrence wrote:
I am receiving this error when I build:
josh@studiobox:~/src/yoshimi-0.009/src$ make
[ 1%] Building CXX object CMakeFiles/yoshimi.dir/MusicIO/JackEngine.cpp.o
/home/josh/src/yoshimi-0.009/src/MusicIO/JackEngine.cpp: In member
function ‘bool JackEngine::Start()’:
/home/josh/src/yoshimi-0.009/src/MusicIO/JackEngine.cpp:90: error:
‘jack_set_info_function’ was not declared in this scope
make[2]: *** [CMakeFiles/yoshimi.dir/MusicIO/JackEngine.cpp.o] Error 1
make[1]: *** [CMakeFiles/yoshimi.dir/all] Error 2
make: *** [all] Error 2
This might be useful, I am running Debian Lenny:
josh@studiobox:~/src/yoshimi-0.009/src$ jackd -v
jackd 0.109.2
I also have libjack-dev installed. Am I doing something wrong? Any
help would be appreciated, I'm excited about this!
As best I can tell, jackd 0.109.2 didn't have jack_set_info_function. While
the jack info callback doesn't serve any huge purpose in this context, and
therefore could be left out of yoshi, 0.109.2 was released January 2008,
which is a long, long time ago. I suggest you consider installing an up to
date version of jack. On lenny, that'll probably mean compiling it yourself.
If you go that way, getting rid of the debian jackd mess first is very
important.
cheers, Cal
6:22 a.m.
cal wrote:
If you go that way, getting rid of the debian jackd
mess first is very
important.
I seem to remember Paul Davis advised to install *on top of* the debian
installation, could you please correct me if I'm wrong, Paul?
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
10:31 a.m.
On Thu, Sep 17, 2009 at 4:22 AM, Atte Andre Jensen
<atte.jensen(a)gmail.com> wrote:
cal wrote:
my preferred approach to this problem is to use the distro package
manage to remove the package without checking dependencies (for
rpm/yum, that means using the --nodeps flag), and then run ./configure
--prefix=/usr when building JACK.
there are variants on this, of course.
If you go that way, getting rid of the debian
jackd mess first is very
important.
I seem to remember Paul Davis advised to install *on top of* the debian
installation, could you please correct me if I'm wrong, Paul?
10:32 a.m.
On Thu, Sep 17, 2009 at 12:39 AM, cal <cal(a)graggrag.com> wrote:
Josh Lawrence wrote:
jackaudio.org notes that "nobody should be using 0.109 at this point in time".
sometimes, linux distributions make me ill :)
I am receiving this error when I build:
josh@studiobox:~/src/yoshimi-0.009/src$ make
[ 1%] Building CXX object CMakeFiles/yoshimi.dir/MusicIO/JackEngine.cpp.o
/home/josh/src/yoshimi-0.009/src/MusicIO/JackEngine.cpp: In member
function ‘bool JackEngine::Start()’:
/home/josh/src/yoshimi-0.009/src/MusicIO/JackEngine.cpp:90: error:
‘jack_set_info_function’ was not declared in this scope
make[2]: *** [CMakeFiles/yoshimi.dir/MusicIO/JackEngine.cpp.o] Error 1
make[1]: *** [CMakeFiles/yoshimi.dir/all] Error 2
make: *** [all] Error 2
This might be useful, I am running Debian Lenny:
josh@studiobox:~/src/yoshimi-0.009/src$ jackd -v
jackd 0.109.2
I also have libjack-dev installed. Am I doing something wrong? Any
help would be appreciated, I'm excited about this!
As best I can tell, jackd 0.109.2 didn't have jack_set_info_function. While
the jack info callback doesn't serve any huge purpose in this context, and
therefore could be left out of yoshi, 0.109.2 was released January 2008,
which is a long, long time ago. I suggest you consider installing an up to
date version of jack.
11:24 a.m.
On Wed, Sep 16, 2009 at 11:39 PM, cal <cal(a)graggrag.com> wrote:
As best I can tell, jackd 0.109.2 didn't have
jack_set_info_function. While
the jack info callback doesn't serve any huge purpose in this context, and
therefore could be left out of yoshi, 0.109.2 was released January 2008,
which is a long, long time ago. I suggest you consider installing an up to
date version of jack. On lenny, that'll probably mean compiling it yourself.
If you go that way, getting rid of the debian jackd mess first is very
important.
I kind of figured that I might have an issue with my version of jack,
so I took it upon myself to seek out 64studio's lenny backports and
added them to my /etc/apt/sources.list. I dist-upgraded my way to
recent jack happiness, and was able to play with the synth - it works
wonderfully!
--
Josh Lawrence
http://www.hardbop200.com
19 Sep
19 Sep
1:53 a.m.
On Thu, Sep 17, 2009 at 08:24:50AM -0500, Josh Lawrence wrote:
On Wed, Sep 16, 2009 at 11:39 PM, cal
<cal(a)graggrag.com> wrote:
Yep. I grabbed the Debian source package of 0.116 from somewhere--
maybe 64studio, maybe Sid--, then built it and installed it
earlier this year. No prob, been using it live for quite some time
now.
EEE Atom-optimized binaries here:
http://www.restivo.org/projects/eee/debs/
-ken
As best I can tell, jackd 0.109.2 didn't have
jack_set_info_function. While
the jack info callback doesn't serve any huge purpose in this context, and
therefore could be left out of yoshi, 0.109.2 was released January 2008,
which is a long, long time ago. I suggest you consider installing an up to
date version of jack. On lenny, that'll probably mean compiling it yourself.
If you go that way, getting rid of the debian jackd mess first is very
important.
I kind of figured that I might have an issue with my version of jack,
so I took it upon myself to seek out 64studio's lenny backports and
added them to my /etc/apt/sources.list. I dist-upgraded my way to
recent jack happiness, and was able to play with the synth - it works
wonderfully!
6:08 a.m.
Ken Restivo wrote:
On Thu, Sep 17, 2009 at 08:24:50AM -0500, Josh
Lawrence wrote:
> On Wed, Sep 16, 2009 at 11:39 PM, cal <cal(a)graggrag.com> wrote:
>
>> As best I can tell, jackd 0.109.2 didn't have jack_set_info_function. While
>> the jack info callback doesn't serve any huge purpose in this context, and
>> therefore could be left out of yoshi, 0.109.2 was released January 2008,
>> which is a long, long time ago. I suggest you consider installing an up to
>> date version of jack. On lenny, that'll probably mean compiling it yourself.
>> If you go that way, getting rid of the debian jackd mess first is very
>> important.
>>
> I kind of figured that I might have an issue with my version of jack,
> so I took it upon myself to seek out 64studio's lenny backports and
> added them to my /etc/apt/sources.list. I dist-upgraded my way to
> recent jack happiness, and was able to play with the synth - it works
> wonderfully!
>
>
Ok, I upgraded to jackd 1.9 from 64studio. It performs much better now.
All though I have about 1000 xruns after playing with it and changing
some banks (I used the Debian default kernel, which is good for other
apps I used, but I'll try the 64studio kernel later)
So the Jack support of Zyn is getting better with newer jack but it
needs quite some improvements too..
I also get messages in my terminal
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
\r
7:04 a.m.
rosea grammostola wrote:
Ken Restivo wrote:
Ok, did some testing with the 64studio RT kernel. No scientific research
though...
The kernel improves it a bit. So do setting off realtime in jackd.
The thing improves it the most is upgrading jack to 1.9
Also enlarging frames/period improves is pretty much.
But still a lot of xruns and sometimes little ticks and clicks. Not all
the banks perform equally well...
I still got
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
So enough things left to improve things.
@Ken, I can imagine you use this thing live with a certain instrument
bank, but imo this is absolutely not enough quality and stability for
using it as live synth, especially not if you want to use different
banks. We shouldn't put our standards to low imho... This is f*cking
Linux Audio you know... ;)
On Thu, Sep 17, 2009 at 08:24:50AM -0500, Josh
Lawrence wrote:
> On Wed, Sep 16, 2009 at 11:39 PM, cal <cal(a)graggrag.com> wrote:
>
>> As best I can tell, jackd 0.109.2 didn't have
>> jack_set_info_function. While
>> the jack info callback doesn't serve any huge purpose in this
>> context, and
>> therefore could be left out of yoshi, 0.109.2 was released January
>> 2008,
>> which is a long, long time ago. I suggest you consider installing
>> an up to
>> date version of jack. On lenny, that'll probably mean compiling it
>> yourself.
>> If you go that way, getting rid of the debian jackd mess first is very
>> important.
>>
> I kind of figured that I might have an issue with my version of jack,
> so I took it upon myself to seek out 64studio's lenny backports and
> added them to my /etc/apt/sources.list. I dist-upgraded my way to
> recent jack happiness, and was able to play with the synth - it works
> wonderfully!
>
>
Ok, I upgraded to jackd 1.9 from 64studio. It performs much better now.
All though I have about 1000 xruns after playing with it and changing
some banks (I used the Debian default kernel, which is good for other
apps I used, but I'll try the 64studio kernel later)
So the Jack support of Zyn is getting better with newer jack but it
needs quite some improvements too..
I also get messages in my terminal
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
jack client reports error: JackActivationCount::Signal value = 0 ref = 4
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
Too may notes - notes > poliphony, PartNoteOn()
\r
5596
days inactive
5601
days old
linux-audio-user@lists.linuxaudio.org
68 comments
14 participants
participants (14)
-
Atte Andre Jensen -
cal -
Dominic Sacré -
Folderol -
Fons Adriaensen -
Gabriel M. Beddingfield -
Garry Ogle -
Grammostola Rosea -
hollunder＠gmx.at -
Josh Lawrence -
Ken Restivo -
Norval Watson -
Paul Davis -
rosea grammostola