2 Feb
2007
2 Feb
'07
9:47 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I looked at this and went, huh?
http://www.zebrasynth.com/
At first glance, it looks like a closed, commercial, aggressively copy-protected clone of
ZynAddSubFX (with a much slicker GUI)?
Wish there were a way to approach all the talented hackers who are unfortunately wasting
their time working on trying to crack it, and instead get them a copy of the Zyn source,
to revamp it from scratch and make it RT-safe.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFw+mZe8HF+6xeOIcRAnNAAKDebkBipozmn+5QzWfXEusOl0JXAgCeOIlI
7pPeqlDYXzcJK39eKKj6yxE=
=QBbp
-----END PGP SIGNATURE-----
2 Feb
2 Feb
10:57 p.m.
On Fri Feb 02, 2007 at 05:47:05PM -0800, Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I looked at this and went, huh?
http://www.zebrasynth.com/
At first glance, it looks like a closed, commercial, aggressively copy-protected clone of
ZynAddSubFX (with a much slicker GUI)?
it does? it just looks like yet another windows VST synth to me.
Wish there were a way to approach all the talented hackers who are unfortunately wasting
their time working on trying to crack it
the small clique of 'talented' hackers, the ones who continually change their name
to things like Radium*, (Mid)Air*, Oxygen(8)*, H2O, ArcTic, (O)Zone*, etc, dont even
bother cracking things that are challenging anymore. like the recent versions of
Samplitude and Cubase. who knows, maybe half of them have switched to linux for their own
music making. and its not like they have a real incentive to provide for a bunch of
lamers, other than boredom.
* if selling a bunch of deliberate plasticy junk wasnt enough to make M-Audio lame, how
about naming all their MIDI controllers after cracking groups?
, and instead get them a copy of the Zyn source, to
revamp it from scratch and make it RT-safe.
how would U-He get paid to do that?
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFw+mZe8HF+6xeOIcRAnNAAKDebkBipozmn+5QzWfXEusOl0JXAgCeOIlI
7pPeqlDYXzcJK39eKKj6yxE=
=QBbp
-----END PGP SIGNATURE-----
11:11 p.m.
On 2/2/07, carmen <_(a)whats-your.name> wrote:
the small clique of 'talented' hackers, the
ones who continually change their name to things like Radium*, (Mid)Air*, Oxygen(8)*, H2O,
ArcTic, (O)Zone*, etc, dont even bother cracking things that are challenging anymore. like
the recent versions of Samplitude and Cubase. who knows, maybe half of them have switched
to linux for their own music making. and its not like they have a real incentive to
provide for a bunch of lamers, other than boredom.
Yep, it's sad to see all those reverse engineering skills wasted on
cracking Windows junk when they could be doing something useful like
improving Linux driver support...
Lee
11:51 p.m.
On Fri, 2007-02-02 at 21:57 -0500, carmen wrote:
* if selling a bunch of deliberate plasticy junk wasnt
enough to make M-Audio lame, how about naming all their MIDI controllers after cracking
groups?
they did?
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
11:59 p.m.
On Sat Feb 03, 2007 at 04:51:00AM +0100, Leonard Ritter wrote:
On Fri, 2007-02-02 at 21:57 -0500, carmen wrote:
Rls Group M-Audio MIDI Controller
_______________________________________
Radium Radium
AiR MidAir
OxYGeN Oxygen
Zone Ozone
sorry, capitalization might not be accurate, i stopped downloading cracks when i switched
to linux.
the reason i dont buy their stuff is beacuse the products are uninspired, ugly, and cheap
build compared to KORG, and high on prices and low on features compared to CME. but the
lame naming scheme, and general lock-in/tie-in attempts with Protools LE and lack of
acknowledging linux's existence doesn't help..
* if selling a bunch of deliberate plasticy junk
wasnt enough to make M-Audio lame, how about naming all their MIDI controllers after
cracking groups?
they did?
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
3 Feb
3 Feb
12:37 a.m.
New subject: [linux-audio-user] M-Audio flameage
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Feb 02, 2007 at 11:00:04PM -0500, carmen wrote:
On Sat Feb 03, 2007 at 04:51:00AM +0100, Leonard
Ritter wrote:
I bought a M-Audio Keystation Pro 88 and I like it. Yeah, it's cheap plastic
'junk', and I don't dare try to take it to a gig, because it'll probably
fall apart, but for home recording it gives me 88 weighted keys and lots of buttons and
knobs to assign to AMS parameters.
Is there KORG or CME equivalent that I missed when I was shopping for this thing? It
ain't too late for me to put the thing up on Craigslist and get rid of it, if
there's a better alternative out there I should be looking at.
- -ken
On Fri, 2007-02-02 at 21:57 -0500, carmen wrote:
Rls Group M-Audio MIDI Controller
_______________________________________
Radium Radium
AiR MidAir
OxYGeN Oxygen
Zone Ozone
sorry, capitalization might not be accurate, i stopped downloading cracks when i switched
to linux.
the reason i dont buy their stuff is beacuse the products are uninspired, ugly, and cheap
build compared to KORG, and high on prices and low on features compared to CME. but the
lame naming scheme, and general lock-in/tie-in attempts with Protools LE and lack of
acknowledging linux's existence doesn't help..
* if selling a bunch of deliberate plasticy junk
wasnt enough to make M-Audio lame, how about naming all their MIDI controllers after
cracking groups?
they did? -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFxBFge8HF+6xeOIcRAiqqAKCXY6JWjbCkN5Oc6KkgfJ764qhf1ACfcPjn
A+52iGS7YG0oAnj2XIguJgQ=
=xbns
-----END PGP SIGNATURE-----
4 Feb
4 Feb
10:46 p.m.
On Fri, Feb 02, 2007 at 11:00:04PM -0500, carmen wrote:
the reason i dont buy their stuff is beacuse the
products are uninspired, ugly, and cheap build compared to KORG, and high on prices and
low on features compared to CME. but the lame naming scheme, and general lock-in/tie-in
attempts with Protools LE and lack of acknowledging linux's existence doesn't
help..
Just to put a different spin on this, I have bought a couple of M-Audio
products and find them to be elegant, minimalist, and cheap (in a
good way). Basically they have the exact functionality I need for the
cheapest price. I have taken one of the units (uc33) to several gigs,
and across the country a couple of times, and it's worked flawlessly for
a couple of years. I bought it second hand. Also, they work just fine
with Linux's usb-audio and usb-midi drivers so I can ditch the driver
CD that comes with them and I know nothing about lock-in/tie-in attempts
with any other (windows) software.
I have no association whatsoever with M-Audio, I just like these two
products of theirs I've bought and thought I'd add my 2c.
Best,
Chris.
-------------------
chris(a)mccormick.cx
http://mccormick.cx
11:30 p.m.
On Mon, 2007-02-05 at 10:22 +0800, Chris McCormick wrote:
I have no association whatsoever with M-Audio, I just
like these two
products of theirs I've bought and thought I'd add my 2c.
i have an unused m-audio firewire 410 which is as of now not working on
linux. i contacted m-audio asking about development support, and after a
bit of moaning they connected me to a developer who said that the
drivers had been developed by a third party (they also said who). i
contacted that third party and they did not call back.
so far i have to say m-audio has not dissatisfied me, but i'd wish
they'd think more of the non-windows platforms. however i heard that the
fw 410 was the first in the series and subsequent firewire audio devices
use the full bebob standard, no custom com. interface involved.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
3 Feb
3 Feb
12:01 a.m.
On 2/2/07, Leonard Ritter <contact(a)leonard-ritter.com> wrote:
On Fri, 2007-02-02 at 21:57 -0500, carmen wrote:
Now that's brilliantly cynical marketing. What are "ArcTic" and
"(O)Zone*" going to do, sue them? It would be like calling the cops
to report your weed stolen...
Lee
* if selling a bunch of deliberate plasticy junk
wasnt enough to make M-Audio lame, how about naming all their MIDI controllers after
cracking groups?
they did?
5:48 a.m.
how would U-He get paid to do that?
No need for. A young talented hacker from Italy named Kunitoki has realised
the potential of native vst on linux, ported zynadd and by the way he cleaned
up the UI:
http://people.jacklab.net/metasymbol/pixel/eXT2-zynadd-native-vst.png
Thats inside the great energyXT2 - the first native VST host for linux with
now 40 native VST plugs.
Uhhh did I say Yahwe? energyXT2 is closed software.
zynadd-vst isn't officialy released now (Kunitoki will clean up some rt
issues - he said the code inside zynadd is a nightmare) and never will be
available as binary, because of restrictions of the GPL.
But works great on my JAD alpha1. Happy prerelease tester.
Kunitoki also ported some other VST Instruments and works heavy on a first
commercial VST Synth for Linux.
The musican world outside the LAU will be very thankfull and they are now,
because energyXT2 is a great piece of Software - simply works.
regards,
Michael
--
.:www.jacklab.net:.
ProAudio for openSUSE Linux
6:11 a.m.
On Sat, 2007-02-03 at 09:57 +0100, Michael Bohle wrote:
The musican world outside the LAU will be very
thankfull and they are now,
because energyXT2 is a great piece of Software - simply works.
this will pass, too.
i did not switch to a free platform to have all the jailers follow me.
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
7:51 a.m.
Am Samstag, 3. Februar 2007 11:11 schrieb Leonard Ritter:
On Sat, 2007-02-03 at 09:57 +0100, Michael Bohle
wrote:
Maybe it will pass one day. But in between we can do some music. I don't want
to blame the free software: it is great what the devs like you do.
But the difference: I can work careless creative with eXT2. But with most of
the free software I've been waiting since years for a intuitive and stable
using of a studio-sequencer with plugins on Linux.
But it is not everything is so closed as it seemed. the audio I/O is public
domain, so the Drumfix made a better one then Jorgen ever made.
So i made an inofficial website for energyXT2 Linux, for featuring the better
and free jack / alsaseq interface (libaam.so), because Jorgen still release
his old buggy one on his official website.
http://people.jacklab.net/metasymbol/software/
regards,
Michael
The musican world outside the LAU will be very
thankfull and they are
now, because energyXT2 is a great piece of Software - simply works.
this will pass, too.
i did not switch to a free platform to have all the jailers follow me.
--
.:www.jacklab.net:.
ProAudio for openSUSE Linux
4 Feb
4 Feb
10:48 p.m.
On Sat, Feb 03, 2007 at 11:59:45AM +0100, Michael Bohle wrote:
Am Samstag, 3. Februar 2007 11:11 schrieb Leonard
Ritter:
But the difference: I can work careless creative with eXT2. But with most of
the free software I've been waiting since years for a intuitive and stable
using of a studio-sequencer with plugins on Linux.
I have been writing some music lately with Modplug tracker (GPL)
running under Wine on Linux. You can use VSTs just fine if you want
(even FOSS ones!). It makes an excellent, intuitive, stable sequencer,
with plugins and all.
Best,
Chris.
-------------------
chris(a)mccormick.cx
http://mccormick.cx
3 Feb
3 Feb
4 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Feb 03, 2007 at 09:57:16AM +0100, Michael Bohle wrote:
Heh, wrong direction.
I was suggesting recruiting people who were wasting their time cracking closed software,
to instead port/clone closed VST instruments to work on LADSPA/DSSI on Linux.
It would be exactly backwards to port/clone closed, proprietary "VST hosts" to
run on Linux. I wouldn't advise that at all.
- -ken
how would U-He get paid to do that?
No need for. A young talented hacker from Italy named Kunitoki has realised
the potential of native vst on linux, ported zynadd and by the way he cleaned
up the UI:
http://people.jacklab.net/metasymbol/pixel/eXT2-zynadd-native-vst.png
Thats inside the great energyXT2 - the first native VST host for linux with
now 40 native VST plugs.
Uhhh did I say Yahwe? energyXT2 is closed software.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFxOnOe8HF+6xeOIcRAqSaAKDPIPjIy1vxOgpFT19ZVSyYwEh3sgCg1rd7
xjhHCrkWvjcK5YjQL2pKIVs=
=AZjI
-----END PGP SIGNATURE-----
10 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ken Restivo schrieb:
On Sat, Feb 03, 2007 at 09:57:16AM +0100, Michael
Bohle wrote:
native Linux-VST may be nice but still there would be
Licence-Restrictions so having LADSPA being made more powerfull is much
better in the long run.
VST is great, powerfull, well-designed etc but I want freedom - so
LADSPA and DSSI is all we have now - VST has no future for people
thinking the free software way ...
> how would U-He get paid to do that?
No need for. A young talented hacker from Italy
named Kunitoki has realised
the potential of native vst on linux, ported zynadd and by the way he cleaned
up the UI:
Thats inside the great energyXT2 - the first
native VST host for linux with
now 40 native VST plugs.
Uhhh did I say Yahwe? energyXT2 is closed
software.
Heh, wrong direction.
I was suggesting recruiting people who were wasting their time cracking closed software,
to instead port/clone closed VST instruments to work on LADSPA/DSSI on Linux.
It would be exactly backwards to port/clone closed, proprietary "VST hosts" to
run on Linux. I wouldn't advise that at all.
-ken -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFxT5Z1Aecwva1SWMRAvSbAKCJ5egbc+58ANkjqfbV+VCaZ5RGhACeN11O
Oq5Cy3SLPmRbIChl0/K7RFw=
=77Up
-----END PGP SIGNATURE-----
2:01 a.m.
On Fri, 2 Feb 2007, Ken Restivo wrote:
Wish there were a way to approach all the talented
hackers who are unfortunately wasting their time working on trying to crack it, and
instead get them a copy of the Zyn source, to revamp it from scratch and make it RT-safe.
Zyn isn't RT safe? Could you elaborate or point to a link? I remember
reading something about this, and was hoping to use it for live
performance.
Larry Troxler
10:39 a.m.
On Sat, 3 Feb 2007 01:01:18 -0500 (EST)
Larry Troxler <lt(a)westnet.com> wrote:
On Fri, 2 Feb 2007, Ken Restivo wrote:
I have heard several comments to this effect, and also that the code
in Zyn is 'a nightmare' however I have not heard anything specific that
one can really get a handle on.
While I agree the GUI is poor and could do with quite a lot of work, I
don't know about the rest, although there are changes I would like in
the way voice banks are managed.
This all causes me quite a lot of concern. I find that Zyn gives
unparallelled results, and conceptually most closely matches my grasp
of sound. I am concerned about talk of unspecified jack problems, and
also the lack of any visible development by the originator.
I, personally, would be willing to expend a great deal of effort to
help revive Zyn, and would be quite happy to put my hand in my
pocket as well.
--
Will J G
Wish there were a way to approach all the
talented hackers who are unfortunately wasting their time working on trying to crack it,
and instead get them a copy of the Zyn source, to revamp it from scratch and make it
RT-safe.
Zyn isn't RT safe? Could you elaborate or point to a link? I remember
reading something about this, and was hoping to use it for live
performance.
Larry Troxler 
10:50 a.m.
On Sat, 2007-02-03 at 14:39 +0000, Folderol wrote:
On Sat, 3 Feb 2007 01:01:18 -0500 (EST)
Larry Troxler <lt(a)westnet.com> wrote:
I wouldn't say that it's a "nightmare", but it's not designed with
RT-safety in mind. For example, there is a big mutex protecting some of
the data structures that is locked from the audio thread, from the MIDI
thread (in the case of ALSA MIDI) and from the GUI thread, which will
cause audio glitches if the mutex is busy when the audio thread tries to
lock it. And some other things. The actual synth algorithms are great,
and it would be very nice if someone could clean it up a bit and make it
a proper JACK client (or plugin, or whatever - as long as it's RT-safe).
--ll
On Fri, 2 Feb 2007, Ken Restivo wrote:
I have heard several comments to this effect, and also that the code
in Zyn is 'a nightmare' however I have not heard anything specific that
one can really get a handle on. Wish there were a way to approach all the
talented hackers who are
unfortunately wasting their time working on trying to crack it,
and instead get them a copy of the Zyn source, to revamp it from
scratch and make it RT-safe.
Zyn isn't RT safe? Could you elaborate or point to a link? I remember
reading something about this, and was hoping to use it for live
performance.
11:25 a.m.
On Sat, 03 Feb 2007 15:49:25 +0100
Lars Luthman <lars.luthman(a)gmail.com> wrote:
On Sat, 2007-02-03 at 14:39 +0000, Folderol wrote:
Ok I can understand that... to some degree.
Why is there any lock capability from the GUI? Surely, as this is not in
any way time critical, it should be able to operate in the 'spaces'
left by the audio & MIDI?
Also (and I speak from the depths of ignorance here) I can't see any
circumstance for MIDI wanting to lock out audio. If there are MIDI
signals wanting to change the data then surely it would make sense to
wait in some form of queue, dipping in quickly between buffer fills.
Subjectively I would expect minor MIDI time discrepancies would be
unnoticed if the average time remained constant.
BTW I'm desperately looking for excuses to avoid doing home repairs
today so if anyone wants to come in on this discussion please do :)
My apologies if anyone thinks this isn't really the right list for
this discussion!
--
Will J G
On Sat, 3 Feb 2007 01:01:18 -0500 (EST)
Larry Troxler <lt(a)westnet.com> wrote:
I wouldn't say that it's a "nightmare", but it's not designed with
RT-safety in mind. For example, there is a big mutex protecting some of
the data structures that is locked from the audio thread, from the MIDI
thread (in the case of ALSA MIDI) and from the GUI thread, which will
cause audio glitches if the mutex is busy when the audio thread tries to
lock it. And some other things. The actual synth algorithms are great,
and it would be very nice if someone could clean it up a bit and make it
a proper JACK client (or plugin, or whatever - as long as it's RT-safe).
--ll On Fri, 2 Feb 2007, Ken Restivo wrote:
I have heard several comments to this effect, and also that the code
in Zyn is 'a nightmare' however I have not heard anything specific that
one can really get a handle on. Wish there were a way to approach all the
talented hackers who are
unfortunately wasting their time working on trying to crack it,
and instead get them a copy of the Zyn source, to revamp it from
scratch and make it RT-safe.
Zyn isn't RT safe? Could you elaborate or point to a link? I remember
reading something about this, and was hoping to use it for live
performance.
11:47 a.m.
On Sat, 2007-02-03 at 15:25 +0000, Folderol wrote:
On Sat, 03 Feb 2007 15:49:25 +0100
Lars Luthman <lars.luthman(a)gmail.com> wrote:
The locks don't really have anything to do with timing, they are used to
protect data structures. The GUI thread may e.g. create a new instance
of an insertion effect, which needs to be inserted into the main engine
for the audio thread to use it. Since all sorts of havoc could ensue if
the audio thread tried to access a partially created effect instance,
the GUI thread locks the mutex while creating the effect and modifying
the data structures.
On Sat, 2007-02-03 at 14:39 +0000, Folderol
wrote:
Ok I can understand that... to some degree.
Why is there any lock capability from the GUI? Surely, as this is not in
any way time critical, it should be able to operate in the 'spaces'
left by the audio & MIDI? On Sat, 3 Feb 2007 01:01:18 -0500 (EST)
Larry Troxler <lt(a)westnet.com> wrote:
I wouldn't say that it's a "nightmare", but it's not designed with
RT-safety in mind. For example, there is a big mutex protecting some of
the data structures that is locked from the audio thread, from the MIDI
thread (in the case of ALSA MIDI) and from the GUI thread, which will
cause audio glitches if the mutex is busy when the audio thread tries to
lock it. And some other things. The actual synth algorithms are great,
and it would be very nice if someone could clean it up a bit and make it
a proper JACK client (or plugin, or whatever - as long as it's RT-safe). On Fri, 2 Feb 2007, Ken Restivo wrote:
> Wish there were a way to approach all the talented hackers who are
> unfortunately wasting their time working on trying to crack it,
> and instead get them a copy of the Zyn source, to revamp it from
> scratch and make it RT-safe.
Zyn isn't RT safe? Could you elaborate or point to a link? I remember
reading something about this, and was hoping to use it for live
performance.
I have heard several comments to this effect, and also that the code
in Zyn is 'a nightmare' however I have not heard anything specific that
one can really get a handle on. Also (and I speak from the depths of ignorance here) I
can't see any
circumstance for MIDI wanting to lock out audio. If there are MIDI
signals wanting to change the data then surely it would make sense to
wait in some form of queue, dipping in quickly between buffer fills.
The MIDI thread creates new notes and changes parameters in response to
MIDI events that the audio thread will need to know about in order to
render said notes with said parameters. To avoid the same problem as the
GUI (audio thread accessing partially updated data structures), it locks
the mutex while doing these changes.
There are ways to do this without blocking the audio thread, but it
requires a bit of clever programming and if you don't think about it
from the start it can require a more or less complete redesign to fix
it.
--ll
12:10 p.m.
On Sat, 03 Feb 2007 16:42:50 +0100
Lars Luthman <lars.luthman(a)gmail.com> wrote:
Ah! I was rather assuming some kind of double buffering would be used
rather like we used to use for the BBC B Model B screens - yes *that*
long ago :)
If buffering is the problem, would it not be possible (say) to indirect
whatever pointers there are to the data so that the routine which
wishes to make changes grabs a new chunk of memory, swapping the
pointers once it has completed the change.
If the reading routine only grabs the indirected pointers at the start
of its buffer then it won't notice the change until it has to go back
to the beginning of the data. If it sees that the pointers have
changed it can presumably hand off the old data to whatever garbage
routine is in place, then carry on with the new pointers.
--
Will J G
On Sat, 2007-02-03 at 15:25 +0000, Folderol wrote:
Why is there
any lock capability from the GUI? Surely, as this is not in
any way time critical, it should be able to operate in the 'spaces'
left by the audio & MIDI?
The locks don't really have anything to do with timing, they are used to
protect data structures. The GUI thread may e.g. create a new instance
of an insertion effect, which needs to be inserted into the main engine
for the audio thread to use it. Since all sorts of havoc could ensue if
the audio thread tried to access a partially created effect instance,
the GUI thread locks the mutex while creating the effect and modifying
the data structures. Also (and I
speak from the depths of ignorance here) I can't see any
circumstance for MIDI wanting to lock out audio. If there are MIDI
signals wanting to change the data then surely it would make sense to
wait in some form of queue, dipping in quickly between buffer fills.
The MIDI thread creates new notes and changes parameters in response to
MIDI events that the audio thread will need to know about in order to
render said notes with said parameters. To avoid the same problem as the
GUI (audio thread accessing partially updated data structures), it locks
the mutex while doing these changes.
There are ways to do this without blocking the audio thread, but it
requires a bit of clever programming and if you don't think about it
from the start it can require a more or less complete redesign to fix
it.
--ll 
11:06 a.m.
Folderol wrote:
On Sat, 3 Feb 2007 01:01:18 -0500 (EST)
Larry Troxler <lt(a)westnet.com> wrote:
Zyn will occasionally just pop itself out of the JACK graph, I'm not
sure why. Paul Nasca had talked about upgrading Zyn's JACK support, but
I don't think he ever got around to it.
Personally I don't mind the GUI. Zyn is a rather "deep" synth, I
certainly wouldn't want to see all of its controls in one panel or even
two. However, I will agree that its interface design does make it
problematic to program. Fortunately its included sounds work beautifully
for my purposes.
Finally though, Zyn is open-source and GPL'd, so whoever wants to pick
up the torch is more than welcome to do so. I have no idea how its code
looks, and I'm not likely to make the effort to find out (IANALAD), but
surely there's a fledgling (or not-so-fledgling) Linux audio developer
out there who wants to make a significant contribution to the Linux
audio workplace ? A stable JACKified Zyn seems to rank highly on users'
wish-lists.
yn isn't RT safe? Could you elaborate or point
to a link? I remember
reading something about this, and was hoping to use it for live
performance.
I have heard several comments to this effect, and also that the code
in Zyn is 'a nightmare' however I have not heard anything specific that
one can really get a handle on.
While I agree the GUI is poor and could do with quite a lot of work, I
don't know about the rest, although there are changes I would like in
the way voice banks are managed.
This all causes me quite a lot of concern. I find that Zyn gives
unparallelled results, and conceptually most closely matches my grasp
of sound. I am concerned about talk of unspecified jack problems, and
also the lack of any visible development by the originator.
I, personally, would be willing to expend a great deal
of effort to
help revive Zyn, and would be quite happy to put my hand in my
pocket as well.
Developers, are you listening ? The man is offering his time *and* his
money. And are any other users out there who are willing to pony up some
dough for a bounty on this item ? (Assuming of course that the task is
actually do-able within a reasonable time).
Synth development in Linux has seen a severe slowdown over the past year
or so. We need things like stabilized Zyn, Om (or whatever DR wants to
call it these days), and AMS. Or does everyone plan on waiting for
better VSTi support ?
Best,
dp
6 Feb
6 Feb
9:52 a.m.
Dave Phillips skrev:
<...>
Zyn will occasionally just pop itself out of the JACK
graph, I'm not
sure why.
I understand where this is coming from and Zyn is at fault here but the
problem is not as grave as one can be led to believe, Zyn does not HAVE
to be popped out.
This all stems from the fact that Jack by default kicks all clients that
cannot, for whatever reason, meet the deadline for each roundtrip.
Personally I don't think this is a good practice outside of a
development environment, the data may still be useful and the incident
will be logged.
It's a bit like using asserts to make sure you're catching ugly problems
during development but in the release-version asserts are normally disabled.
It is very easy to reconfigure jack to give all applications some slack
using:
jackd -t 4000 -d <backend> -s <your favourite parameters>
-t 4000 extends timeout to 4000 milliseconds
-s sets jack in softmode (set for the backend I believe)
(I think that's the right parameters, don't have acccess to a system
right now.)
Regards,
Robert
3 Feb
3 Feb
11:22 a.m.
Folderol <folderol(a)ukfsn.org> writes:
I, personally, would be willing to expend a great deal
of effort to
help revive Zyn
You can help:
http://home.gna.org/zyn/
and would be quite happy to put my hand in my
pocket as well.
No idea what can be improved with your money but I dont wan't them for
sure.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
5:58 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, Feb 03, 2007 at 05:21:51PM +0200, Nedko Arnaudov wrote:
Folderol <folderol(a)ukfsn.org> writes:
That's fantastic! I'll try to build it, play with it, and have a look at the
source, and see if there is a way I can help.
- -ken
I, personally, would be willing to expend a great
deal of effort to
help revive Zyn
You can help:
http://home.gna.org/zyn/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFxQV9e8HF+6xeOIcRAtBOAJ9LNMlYm219jZ78guGz/Vd1O+zbCgCgj3j+
mVdyceD0DbVSUNzPlV6lybc=
=JqzP
-----END PGP SIGNATURE-----
4 Feb
4 Feb
5:18 a.m.
Nedko Arnaudov wrote:
You can help:
http://home.gna.org/zyn/
Ok, maybe I'm stupid or something, but is there any code available to
download? Which hosts support (or has work being done to support) LV2?
In general what's the status of the project?
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
8:29 a.m.
Atte André Jensen <atte.jensen(a)gmail.com> writes:
Nedko Arnaudov wrote:
It is still in development but I can produce sounds, it is just that not
all parameters are exposed currently. You can obtain current sources
From subversion repoistories. You will need zynadd itself from zyn
project, zynjacku - a LV2 host and lv2dynparam library.
Currently zynadd is most usable in zynjacku. elven and jack_host can
also load it, but (currently?) they don't support dynparam lv2 extension
and you will not see any GUI and you will not be able to control any of
zynadd engine parameters to tweak the sound.
home page of lv2dynparam extension is:
http://home.gna.org/lv2dynparam/
home page of zynjacku extension is:
http://home.gna.org/zynjacku/
Checkout over SVN protocol (TCP 3690):
svn co svn://svn.gna.org/svn/lv2dynparam/code lv2dynparam
svn co svn://svn.gna.org/svn/zynjacku/code zynjacku
svn co svn://svn.gna.org/svn/zyn/code zyn
Checkout over http:
svn co http://svn.gna.org/svn/lv2dynparam/code lv2dynparam
svn co http://svn.gna.org/svn/zynjacku/code zynjacku
svn co http://svn.gna.org/svn/zyn/code zyn
You need to build and install lv2dynparam library first.
Then you need to build and install zynadd plugin itself.
You need to build zynjacku. Currently you cannot install zynjacku
system wide, at least not by using the supplied makefile. You can load
zynadd into zynjacku using command line like this:
<pathto>/zynjacku.py http://home.gna.org/zyn/zynadd/0
You will be able to load plugins from UI, that part is just not ready
yet. You can load multiple LV2 plugins by supplying several plugin
URIs. You will see the multi-synth ui then:
http://nedko.arnaudov.name/tmp/zynjacku.png
It seems to be bug that causes zynjacku segfault when multiple plugins
are specified. I'll fix this ASAP (I've just found it).
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
You can help:
http://home.gna.org/zyn/
Ok, maybe I'm stupid or something, but is there any code available to
download? Which hosts support (or has work being done to support) LV2?
In general what's the status of the project? 
9:13 a.m.
Nedko Arnaudov wrote:
It is still in development but I can produce sounds,
Thanks for the information, I'll check it out asap!
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
10:12 a.m.
On Sun, 04 Feb 2007 14:29:41 +0200
Nedko Arnaudov <nedko(a)arnaudov.name> wrote:
Atte André Jensen <atte.jensen(a)gmail.com>
writes:
<snip>
There seems to be quite a lot to wade through but I will have a look and
see if I can get my head round it.
--
Will J G
Nedko Arnaudov wrote:
It is still in development but I can produce sounds, it is just that not
all parameters are exposed currently. You can obtain current sources
From subversion repoistories. You will need zynadd itself from zyn
project, zynjacku - a LV2 host and lv2dynparam library. You can help:
http://home.gna.org/zyn/
Ok, maybe I'm stupid or something, but is there any code available to
download? Which hosts support (or has work being done to support) LV2?
In general what's the status of the project? 
11:23 a.m.
New subject: [linux-audio-user] ZynAddSubFX patch
Hi,
I've just uploaded a fix for less crackles and less timeouts during
instrument loading and bank switching.
Its against cvs-head. For jackd audio and alsa-sequencer midi.
See
http://sourceforge.net/tracker/index.php?func=detail&aid=1651753&gr…
Karsten
2:51 p.m.
New subject: [linux-audio-user] ZynAddSubFX patch
Karsten Wiese wrote:
Hi,
I've just uploaded a fix for less crackles and less timeouts during
instrument loading and bank switching.
Its against cvs-head. For jackd audio and alsa-sequencer midi.
See
http://sourceforge.net/tracker/index.php?func=detail&aid=1651753&gr…
Karsten
I've edited your patch a bit and also fixed jackmidi breakage
fetch it from:
http://evermind.ev.funpic.de/zyn-patches/
Greetz
Frieder
# this patches apply to 20070204 cvs zynaddsubfx
# 01-mutex-split.patch -- based on
http://sourceforge.net/tracker/index.php?func=detail&aid=1651753&gr…
(the same patch but without jackmidi removal)
# 02-ifdef-jackmidi.patch
makes jackmidi optional (edit Makefile.inc)
# 03-fix_jackmidi.patch
fix jackmidi breakage
3:15 p.m.
New subject: [Zynaddsubfx-user] [linux-audio-user] ZynAddSubFX patch
On Sun, 04 Feb 2007 19:50:53 +0100
Frieder Bürzele <linux-stuff(a)arcor.de> wrote:
Karsten Wiese wrote:
Hmmm. I've forgotten how to get Zyn from cvs. Can someone give me a
reminder please?
--
Will J G
Hi,
I've just uploaded a fix for less crackles and less timeouts during
instrument loading and bank switching.
Its against cvs-head. For jackd audio and alsa-sequencer midi.
See
http://sourceforge.net/tracker/index.php?func=detail&aid=1651753&gr…
Karsten
I've edited your patch a bit and also fixed jackmidi breakage
fetch it from:
http://evermind.ev.funpic.de/zyn-patches/
Greetz
Frieder
# this patches apply to 20070204 cvs zynaddsubfx
# 01-mutex-split.patch -- based on
http://sourceforge.net/tracker/index.php?func=detail&aid=1651753&gr…
(the same patch but without jackmidi removal)
# 02-ifdef-jackmidi.patch
makes jackmidi optional (edit Makefile.inc)
# 03-fix_jackmidi.patch
fix jackmidi breakage
3:34 p.m.
New subject: [Zynaddsubfx-user] [linux-audio-user] ZynAddSubFX patch
Am Sonntag, 4. Februar 2007 20:15 schrieb Folderol:
On Sun, 04 Feb 2007 19:50:53 +0100
Frieder Bürzele <linux-stuff(a)arcor.de> wrote:
See
http://sourceforge.net/cvs/?group_id=62934
Section "Anonymous CVS Access"
Karsten
Karsten Wiese wrote:
Hmmm. I've forgotten how to get Zyn from cvs. Can someone give me a
reminder please? Hi,
I've just uploaded a fix for less crackles and less timeouts during
instrument loading and bank switching.
Its against cvs-head. For jackd audio and alsa-sequencer midi.
See
http://sourceforge.net/tracker/index.php?func=detail&aid=1651753&gr…
Karsten
I've edited your patch a bit and also fixed jackmidi breakage
fetch it from:
http://evermind.ev.funpic.de/zyn-patches/
Greetz
Frieder
# this patches apply to 20070204 cvs zynaddsubfx
# 01-mutex-split.patch -- based on
http://sourceforge.net/tracker/index.php?func=detail&aid=1651753&gr…
(the same patch but without jackmidi removal)
# 02-ifdef-jackmidi.patch
makes jackmidi optional (edit Makefile.inc)
# 03-fix_jackmidi.patch
fix jackmidi breakage
10:09 a.m.
On Sun, 04 Feb 2007 10:18:27 +0100
Atte André Jensen <atte.jensen(a)gmail.com> wrote:
Nedko Arnaudov wrote:
Oh it's not just me then :)
--
Will J G
You can help:
http://home.gna.org/zyn/
Ok, maybe I'm stupid or something, but is there any code available to
download? Which hosts support (or has work being done to support) LV2?
In general what's the status of the project?
3 Feb
3 Feb
12:38 p.m.
New subject: ZynAddSubFx waveform export would be nice / Re: [linux-audio-user] Commercial "clone" of ZynAddSubFX?
Folderol wrote:
On Sat, 3 Feb 2007 01:01:18 -0500 (EST)
Larry Troxler <lt(a)westnet.com> wrote:
What would be nice for me if there was an export feature for the source
waveforms it produces (the ones that are made by constructing a spectrum
with a bandwidth for each of the harmnonics). Then I could use them in
PD or Csound or ??? .
Anyone else here have this thought (or alternatives)?
Larry Troxler
On Fri, 2 Feb 2007, Ken Restivo wrote:
I have heard several comments to this effect, and also that the code
in Zyn is 'a nightmare' however I have not heard anything specific that
one can really get a handle on.
While I agree the GUI is poor and could do with quite a lot of work, I
don't know about the rest, although there are changes I would like in
the way voice banks are managed.
This all causes me quite a lot of concern. I find that Zyn gives
unparallelled results, and conceptually most closely matches my grasp
of sound. I am concerned about talk of unspecified jack problems, and
also the lack of any visible development by the originator.
I, personally, would be willing to expend a great deal of effort to
help revive Zyn, and would be quite happy to put my hand in my
pocket as well.
Wish there were a way to approach all the
talented hackers who are unfortunately wasting their time working on trying to crack it,
and instead get them a copy of the Zyn source, to revamp it from scratch and make it
RT-safe.
Zyn isn't RT safe? Could you elaborate or point to a link? I remember
reading something about this, and was hoping to use it for live
performance.
Larry Troxler
4 Feb
4 Feb
5:23 a.m.
New subject: ZynAddSubFx waveform export would be nice / Re: [linux-audio-user] Commercial "clone" of ZynAddSubFX?
Larry Troxler wrote:
Anyone else here have this thought (or alternatives)?
In csound you could use GEN10:
http://www.csounds.com/manual/html/GEN10.html. In csound context that's
much faster and much more flexible.
I had some success by loading some d50 spectra in snd and approximating
the strength of overtones and then recreating them with GEN10.
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
3 Feb
3 Feb
5:21 a.m.
Am Samstag, 3. Februar 2007 02:47 schrieb Ken Restivo:
I looked at this and went, huh?
http://www.zebrasynth.com/
At first glance, it looks like a closed, commercial, aggressively
copy-protected clone of ZynAddSubFX (with a much slicker GUI)?
Paranoia?
Urs Heckmann is a talented and creative sounddesigner / developer and does not
need to clone some buggy linux stuff....
regards,
Michael
Wish there were a way to approach all the talented hackers who are
unfortunately wasting their time working on trying to crack it, and instead
get them a copy of the Zyn source, to revamp it from scratch and make it
RT-safe.
-ken
--
.:www.jacklab.net:.
ProAudio for openSUSE Linux
6560
days inactive
6564
days old
linux-audio-user@lists.linuxaudio.org
37 comments
16 participants
participants (16)
-
Atte André Jensen -
carmen -
Chris McCormick -
Dave Phillips -
Folderol -
Frieder Bürzele -
Hartmut Noack -
Karsten Wiese -
Ken Restivo -
Larry Troxler -
Lars Luthman -
Lee Revell -
Leonard Ritter -
Michael Bohle -
Nedko Arnaudov -
Robert Jonsson