7 Jan
2007
7 Jan
'07
7:59 a.m.
Hi
I just rediscovered ams. What a nice synth! Actually I started
implementing some of the few things I feel is missing. However it seems
to me that nobody's using, at least the mailing lists are totally dead. So:
1) Anyone using it?
2) If not, why? Don't need/understand this type of synth? Use something
else (what) instead? Technical reasons/limitations?
3) If you ever tried what did you love about it and what did you hate?
Did you find user friendly? Did it perform well?
4) To rephrase 2): If the project was resurrected, what would it take
for *you* to start using it.
5) Anyone (other than me) looked inside the code and interested in
discussing certain aspects of that? Maybe even a joint effort to repair
the quirks in ams?
Finally let make it clear that I don't have the time or knowledge to
take over development of ams. But I'm interested in helping with
bringing it to a state where it's a bit more usable...
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
7 Jan
7 Jan
8:47 a.m.
Hello
I just rediscovered ams. What a nice synth! Actually I
started
implementing some of the few things I feel is missing. However it seems
to me that nobody's using, at least the mailing lists are totally dead. So:
1) Anyone using it?
I regulary try it and I am really amazed by the sound. But many
parts of
the sound is based on LADSPA plugins and I work now with these in my
preferred environment pd, archieving the same sound.
2) If not, why? Don't need/understand this type of synth? Use something
else (what) instead? Technical reasons/limitations?
Handling is a bit clumsy.
Screen estate is wasted by the big objects, no
subpachtes available and I always accidently connect wrong ports. I
think small changes here and there would have great effects in terms of
usability.
3) If you ever tried what did you love about it and what did you hate?
Did you find user friendly? Did it perform well?
4) To rephrase 2): If the project was resurrected, what would it take
for *you* to start using it.
A nice thing would be a separete storage of patch settings. I want to
create a synthesizer (the patch) and store different sound settings like
on a non modular synth since the 80s. So I can recall different sounds
without reloading the whole dsp graph.
I could also look in the code, its a timeproblem at the moment.
Cheers,
Malte
--
Malte Steiner
media art + development
-www.block4.com-
8:57 a.m.
On Sun, Jan 07, 2007 at 01:27:11PM +0100, Atte André Jensen wrote:
5) Anyone (other than me) looked inside the code and
interested in
discussing certain aspects of that? Maybe even a joint effort to repair
the quirks in ams?
I worked on AMS together with its principal author, Matthias Nagorni.
My contributions were some modules, a complete rewrite of the signal
flow mechanism (wich was originally much more complicated without
any benefit), and the ALSA and JACK audio interfaces.
At that time Matthias was part of the group working on audio at SuSE.
He has now moved on to project management and has no longer the time
to work on AMS.
The place of AMS has largely been taken by Om, and a integration of
the best of AMS into Om would IMHO be a interesting development.
Unfortunately Om does not really support the logarithmic 'control
voltage' concept that is at the heart of AMS and of the analog synths
it was designed to emulate. The reason being AFAICS that Om's author
seems to dislike it and prefers linear controls - we had some heated
exchanges about this. Mixing both paradigms into a single program
*could* indeed confuse some users, but that is a IMHO a matter of
documentation and education.
The quirks of AMS are related to the MIDI interfaces and voice
assignment. While all the other processing code of AMS is fully
dynamic and reconfigurable at any time, these functions use static
objects that are hardwired together, e.g. voice assignment relies
on a hidden feedback channel from the ENV generators to the MIDI
handling code.
Adding multi-timbral patches and dynamic polyphony would require
a complete rewrite of these parts, and considerable changes to
how things are seen by the user, for example the feedback path
mentioned above would need to become explicit, the flexible
assignment of MIDI controllers to module parameters would become
more complicated, etc. The main reasons why it was never done were
that it would be a major rewrite, and break the large collection
of examle patches that Matthias had created.
It's still on my to-do list, but not for any time soon...
--
FA
Lascia la spina, cogli la rosa.
9:08 a.m.
On Sun, 2007-01-07 at 14:59 +0100, Fons Adriaensen wrote:
The place of AMS has largely been taken by Om, and a
integration of
the best of AMS into Om would IMHO be a interesting development.
Unfortunately Om does not really support the logarithmic 'control
voltage' concept that is at the heart of AMS and of the analog synths
it was designed to emulate. The reason being AFAICS that Om's author
seems to dislike it and prefers linear controls - we had some heated
exchanges about this. Mixing both paradigms into a single program
*could* indeed confuse some users, but that is a IMHO a matter of
documentation and education.
Is there really any need for explicit support for logarithmic control in
the engine itself? All ugens in Om/Ingen except for a very small number
that interface with the audio and MIDI ins and outs are LADSPA (or
similar) plugins, it's not as if you can't connect a logarithmic output
port of one plugin to a logarithmic input port of another.
--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
9:27 a.m.
On Sun, Jan 07, 2007 at 03:07:26PM +0100, Lars Luthman wrote:
Is there really any need for explicit support for
logarithmic control in
the engine itself? All ugens in Om/Ingen except for a very small number
that interface with the audio and MIDI ins and outs are LADSPA (or
similar) plugins, it's not as if you can't connect a logarithmic output
port of one plugin to a logarithmic input port of another.
Probably there is no 'technical' problem doing so, but it would mean
you have two sets of modules that are really incompatible with each
other - it could become very confusing to a user. The 'spirit' of Om/
Ingen seems to be linear control, and AFAIK that is a deliberate choice
of its author and one I will respect, even if don't think it's the best
choice for a mainstream synth ('mainstream' used here as opposed to more
abstract environments such as CSound or SuperCollider).
--
FA
Lascia la spina, cogli la rosa.
9:51 a.m.
Hallo,
Fons Adriaensen hat gesagt: // Fons Adriaensen wrote:
Probably there is no 'technical' problem doing
so, but it would mean
you have two sets of modules that are really incompatible with each
other - it could become very confusing to a user. The 'spirit' of Om/
Ingen seems to be linear control, and AFAIK that is a deliberate choice
of its author and one I will respect, even if don't think it's the best
choice for a mainstream synth ('mainstream' used here as opposed to more
abstract environments such as CSound or SuperCollider).
Though I guess I understand what you mean, I'd like to note that
CSound, SuperCollider and Pd are the by far the most widely used [1]
synths on Linux, so one could argue that they are the real
"mainstream" Linux synths. ;)
[1] I'm basing my observation on mailing list subscriber counts and
traffic amounts, which of course is slightly skewed as it includes the
Mac and Windows users of said synths.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
11 a.m.
Hi Frank,
Though I guess I understand what you mean, I'd
like to note that
CSound, SuperCollider and Pd are the by far the most widely used [1]
synths on Linux, so one could argue that they are the real
"mainstream" Linux synths. ;)
I should have written 'CSound, Pd, or SuperCollider' (in ASCII
order) of course :-)
Depends on what you call 'a synth' - each of the above can be used
for emulation of (hardware) synths, but they all go much beyond that,
being more full electro-acoustic composition tools.
--
FA
Lascia la spina, cogli la rosa.
12:37 p.m.
Frank Barknecht wrote:
Though I guess I understand what you mean, I'd
like to note that
CSound, SuperCollider and Pd are the by far the most widely used [1]
synths on Linux, so one could argue that they are the real
"mainstream" Linux synths. ;)
I'm actually quite close to give up on all these GUI synths (and their
unsteady development) and go back to csound (or better yet, figure out
super-collider), because of the stability in development and width in
user community they can offer.
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
8 Jan
8 Jan
4:50 a.m.
Frank Barknecht wrote:
I'm surprised there isn't more talk about supercollider here. From hearing
performances using it, it's sound quality is superb.
cheers,
dave
Though I guess I understand what you mean,
I'd like to note that
CSound, SuperCollider and Pd are the by far the most widely used [1]
synths on Linux, so one could argue that they are the real
"mainstream" Linux synths. ;)
I'm actually quite close to give up on all these GUI synths (and their
unsteady development) and go back to csound (or better yet, figure out
super-collider), because of the stability in development and width in
user community they can offer.
9:19 a.m.
Hallo,
Dave Griffiths hat gesagt: // Dave Griffiths wrote:
I think, talk about CSound, SC and Pd mostly happens on the respective
mailing lists. pd-list and pd-dev for example have more subscribers
than LAU/LAD and a quite a big amount of traffic. There just is no
need to talk about Pd-specific topics on LAU/LAD. I guess it's similar
with SC and Csound. The fact, that there's not that much talk about
the big three on LAD/LAU in no way means they aren't used on Linux.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank
Barknecht wrote:
I'm surprised there isn't more talk about supercollider here. From hearing
performances using it, it's sound quality is superb. Though I guess I understand what you mean,
I'd like to note that
CSound, SuperCollider and Pd are the by far the most widely used [1]
synths on Linux, so one could argue that they are the real
"mainstream" Linux synths. ;)
I'm actually quite close to give up on all these GUI synths (and their
unsteady development) and go back to csound (or better yet, figure out
super-collider), because of the stability in development and width in
user community they can offer.
12:31 p.m.
Frank Barknecht wrote:
Hallo,
Dave Griffiths hat gesagt: // Dave Griffiths wrote:
I think, talk about CSound, SC and Pd mostly happens
on the respective
mailing lists. pd-list and pd-dev for example have more subscribers
than LAU/LAD and a quite a big amount of traffic. There just is no
need to talk about Pd-specific topics on LAU/LAD. I guess it's similar
with SC and Csound.
I can confirm for Csound. Btw Dave, what about Spiralmodular,
I like to
use it but on recent distributions the sound is always sort of
ringmodulated/aliased, is there a simple solution of it? I thought it
would be some sampling frequency mismatch but judging from the settings
its the same as Jacks..
Cheers,
Malte
--
Malte Steiner
media art + development
-www.block4.com-
7 Jan
7 Jan
9:25 a.m.
Atte André Jensen wrote:
I just rediscovered ams. What a nice synth! Actually I
started
implementing some of the few things I feel is missing. However it
seems to me that nobody's using, at least the mailing lists are
totally dead. So:
1) Anyone using it?
I *have* used it, but currently my work doesn't call for it.
2) If not, why? Don't need/understand this type of
synth? Use
something else (what) instead? Technical reasons/limitations?
See above.
3) If you ever tried what did you love about it and
what did you hate?
Did you find user friendly? Did it perform well?
Its GUI wasn't exactly attractive, but I didn't really care too much
about that. And yes, it performed nicely.
4) To rephrase 2): If the project was resurrected,
what would it take
for *you* to start using it.
I don't recall if it's JACKed but that's a must.
5) Anyone (other than me) looked inside the code and
interested in
discussing certain aspects of that? Maybe even a joint effort to
repair the quirks in ams?
Fons probably knows most about it, he contributed bits to the project.
Finally let make it clear that I don't have the
time or knowledge to
take over development of ams. But I'm interested in helping with
bringing it to a state where it's a bit more usable...
A worthy and laudable interest. I'm dismayed by the slowdown re:
development of native Linux synths, and I see more projects languishing
instead of moving forward. Perhaps another relevant question might be,
"Is the native Linux softsynth going the way of the dodo ?". Om/Ingen is
not yet well-prepared for the end-user (though the most recent sources
might have improved the situation), no development has occurred for
ZynAddSubFX for some time, and the list of softsynths at linux-sound.org
has not significantly expanded for a long time. Alas, neither has there
been a rush of new DSSI synths. Good stuff is out there, but it seems to
me that our choices are dwindling.
Don't get me wrong, I like what we have. I just want more. :)
Best,
dp
9:43 a.m.
On Sun, Jan 07, 2007 at 09:36:50AM -0500, Dave Phillips wrote:
I don't recall if it's JACKed but that's a
must.
It is.
A worthy and laudable interest. I'm dismayed by
the slowdown re:
development of native Linux synths, and I see more projects languishing
instead of moving forward.
Dave, do you think there is a place for a softsynth that would be
modular but with a fixed set of modules, everyhing controlled from
one window, no patch cables, only 'hardware controls' such as
sliders and switches, each one assignable to MIDI, and of course
uncompromising audio quality ?
In other words a synth that would be easy to use and optimised for
'live' work, sort of a MiniMoog on steroids ? Polyphonic of course but
not multi-timbral - just start two or three of them if you need that.
--
FA
Lascia la spina, cogli la rosa.
10:11 a.m.
Fons Adriaensen wrote:
Dave, do you think there is a place for a softsynth
that would be
modular but with a fixed set of modules, everyhing controlled from
one window, no patch cables, only 'hardware controls' such as
sliders and switches, each one assignable to MIDI, and of course
uncompromising audio quality ?
In other words a synth that would be easy to use and optimised for
'live' work, sort of a MiniMoog on steroids ? Polyphonic of course but
not multi-timbral - just start two or three of them if you need that.
Sure, the more the merrier. :)
But perhaps Nick Dowell's amSynth already comes close to your suggested
design ? Its GUI certainly got spiffier recently. :)
Current Csound5 is also capable of such designs, examples are already
available with FLTK interfaces, but of course you must know how to
program Csound.
A question for Frank: Can Pd's wiring be made invisible for a finished
patched ? Even with subpatching I get some real rat's nests onscreen.
Best,
dp
10:26 a.m.
Hallo!
A question for Frank: Can Pd's wiring be made
invisible for a finished
patched ? Even with subpatching I get some real rat's nests onscreen.
no, but you can use subpatches with "graph-on-parent" - then you will
only see the gui objects (and no wires or standard objects ...)
LG
Georg
10:56 a.m.
Hallo,
Dave Phillips hat gesagt: // Dave Phillips wrote:
A question for Frank: Can Pd's wiring be made
invisible for a finished
patched ? Even with subpatching I get some real rat's nests onscreen.
You can use the "graph on parent" feature to hide everything except
GUI elements. Both screenshots on
http://en.wikipedia.org/wiki/Pure_data show this in action.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
11:08 a.m.
On Sun, Jan 07, 2007 at 03:47:19PM +0100, Fons Adriaensen wrote:
Dave, do you think there is a place for a softsynth that would be
modular but with a fixed set of modules, everyhing controlled from
one window, no patch cables, only 'hardware controls' such as
sliders and switches, each one assignable to MIDI, and of course
uncompromising audio quality ?
In other words a synth that would be easy to use and optimised for
'live' work, sort of a MiniMoog on steroids ? Polyphonic of course but
not multi-timbral - just start two or three of them if you need that.
In Om, I often find myself building the usual Osc > Filter > Amp
chains (or Amp > Filter). A model that builds on suchs chains,
but allows additional routing could be nice. Maybe with 2 oscs
and filters per chain. It should allow easy layering and rich
CC support.
Another concept worth consideration would be a routing matrix, with
amount of influence in the cells. I asume low to medium complexity
setups could be done very fast, while a graph should be superior
for more complex things.
--
Thorsten Wilms
Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil
8 Jan
8 Jan
11:34 a.m.
> do you think there is a place for a softsynth
that would be
> modular but with a fixed set of modules, everyhing controlled from
> one window, no patch cables, only 'hardware controls' such as
> sliders and switches, each one assignable to MIDI, and of course
> uncompromising audio quality ?
> In other words a synth that would be easy to use and optimised for
> 'live' work, sort of a MiniMoog on steroids ? Polyphonic of course but
> not multi-timbral - just start two or three of them if you need that.
The Bristol 2600 does this, you either use the default patching, or you can
repatch it with cables. The cable patch layer is a transparency and you can
toggle with the 't' key between opaque and transparent to either hide the
spaghetti when programming or show the layer when you are repatching.
Nick.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
1:21 p.m.
On Mon, Jan 08, 2007 at 05:34:08PM +0100, Nick Copeland wrote:
The Bristol 2600 does this, you either use the default
patching, or you can
repatch it with cables. The cable patch layer is a transparency and you can
toggle with the 't' key between opaque and transparent to either hide the
spaghetti when programming or show the layer when you are repatching.
I downloaded Bristol yesterday to have a look at it but didn't manage
to get a single sound out it. It seemed to have problems with ALSA, and even with -jack
tried to use an ALSA device. I'll try again some
time later.
Is Bristol a single 'engine' with a number of interfaces on top of it,
or does it have DSP code specific to a synth type (e.g. the Moog's
filters) ?
--
FA
Lascia la spina, cogli la rosa.
2:30 p.m.
Single engine running different emulations, there are different operators
for some aspects of each synth and some share components. Each GUI
represents the parameters that are used by the given emulation and responds
to MIDI controllers on whatever channel it is configured. The GUI can
actually be a single process as well i.e. the graphics library handles
multiple windows simultaneously its just that the only user interface at the
moment is to start multiple GUI that connect to the same engine. When an
interface is integrated to start synths from within the application then the
GUI and engine could become different threads of the same binary. There
would be some benefits from doing that, but it might make a mess of the
distribution capabilties where the GUI and engine can run on different
systems with X11 output to a 3rd system. I quite like this kind of
multitiered architecture albeit overly complex.
The filters are not 'quite' moog quality - not much of a surprise. There are
some new ones being worked on for the Aks and MS20 that should be a bit
warmer.
Try "startBristol -gain 64 -2600 -jack -logo", this should give you a higher
gain at the output stage. Internal operations are float so this should not
affect the quality excessively. Normalising the different gains is something
I should work on as some synths thump outs sounds at different levels. If in
doubt use the -b3 as it has the highest gain as it has over 90 emulated
toothwheels, but then watch our for different -gain values as the results
could be unexpected. Its my job to do this normalisation, but until people
complain enough that won't happen.
Let me know how '-gain 64' works, I was thinking of making this the default.
Regards,
Nick.
http://bristol.sourceforge.net
From: Fons Adriaensen <fons(a)kokkinizita.net>
Reply-To: A list for linux audio users
<linux-audio-user(a)music.columbia.edu>
To: A list for linux audio users <linux-audio-user(a)music.columbia.edu>
Subject: Re: [linux-audio-user] status of ams
Date: Mon, 8 Jan 2007 19:00:35 +0100
On Mon, Jan 08, 2007 at 05:34:08PM +0100, Nick Copeland wrote:
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
The Bristol 2600 does this, you either use the
default patching, or you
can
repatch it with cables. The cable patch layer is
a transparency and you
can
toggle with the 't' key between opaque
and transparent to either hide
the
spaghetti when programming or show the layer when
you are repatching.
I downloaded Bristol yesterday to have a look at it but didn't manage
to get a single sound out it. It seemed to have problems with ALSA, and
even with -jack tried to use an ALSA device. I'll try again some
time later.
Is Bristol a single 'engine' with a number of interfaces on top of it,
or does it have DSP code specific to a synth type (e.g. the Moog's
filters) ?
--
FA
Lascia la spina, cogli la rosa.
7 Jan
7 Jan
1:13 p.m.
On Sun, Jan 07, 2007 at 03:47:19PM +0100, Fons Adriaensen wrote:
On Sun, Jan 07, 2007 at 09:36:50AM -0500, Dave
Phillips wrote:
Didn't you just describe amSynth ? :-)
I use it frequently, precisely because it's so simple.
Don't know if all its parameters are MIDI-controllable, though.
My current use of synthesis is not very demanding.
--
-PW
I don't recall if it's JACKed but
that's a must.
It is.
A worthy and laudable interest. I'm dismayed
by the slowdown re:
development of native Linux synths, and I see more projects languishing
instead of moving forward.
Dave, do you think there is a place for a softsynth that would be
modular but with a fixed set of modules, everyhing controlled from
one window, no patch cables, only 'hardware controls' such as
sliders and switches, each one assignable to MIDI, and of course
uncompromising audio quality ?
In other words a synth that would be easy to use and optimised for
'live' work, sort of a MiniMoog on steroids ? Polyphonic of course but
not multi-timbral - just start two or three of them if you need that. 
4:43 p.m.
On Sunday 07 January 2007 09:47, Fons Adriaensen wrote:
Dave, do you think there is a place for a softsynth
that would
be modular but with a fixed set of modules, everyhing
controlled from one window, no patch cables, only 'hardware
controls' such as sliders and switches, each one assignable to
MIDI, and of course uncompromising audio quality ?
This is something I had back in my Windows days (can't remember
the name of it, but it was basically a Moog Rogue style
2-oscillator synth with MIDI-mappable controls, and it was
pretty cheap shareware) and I really miss it.
I've tried to recreate that kind of instrument using the various
modular synths under Linux. But the truth is, while I know how
to tweak filter knobs and stuff on a real synth to get the sound
I want, I've never been able to recreate that sort of Moog or
Arp sound that is the whole reason I use simulations of analog
synths in the first place. I'm not in it to be the next Walter
Carlos. I did my time with electronic music experimentation
when I used to roll my own DX7 patches, and that's as far as I
ever want to go with it. Now I just want to compose, arrange
and play using a simulation of an electronic instrument with
which I'm familiar. (I also would like to figure out a way to
convert the GUS patches I made 10 years ago when I was most
productive, the tweaked-out mellotrons and organs and whatnot,
into soundfonts so I can use them with a Fluidsynth DSSI plugin
rather than having to set up Timidity as an ALSA and JACK
client, but that's for another thread.)
Even a nice "mini" or "2600" preset in Pd or ams or Om, which I
could control using the knobs and sliders on my MIDI controller,
would probably be enough to get me going again. Preferably one
that lets me save its current state so I don't have to take
screenshots to remember the settings. I would do it myself but
like I said, I've tried and failed.
Note: I've spent a little time with Bristol's Mini simulation but
haven't had time to figure out how to map MIDI controllers to
its parameters over the last year due to work. I've also played
with Zyn, since it seems the closest to what I have in mind,
though a little more complex, but holy xruns Batman. It seems
on this Ubuntu-preloaded laptop I'll have to roll my own kernel
to get the low-latency stuff in there, and I'm not messing with
my kernel until my current work project is done. Still
irritates me that after all these years we still have to use an
unofficial patch to get audio output as stable as Windows or the
Mac.
Rob
8:14 p.m.
On Sun, Jan 07, 2007 at 04:37:21PM -0500, Rob wrote:
I've tried to recreate that kind of instrument
using the various
modular synths under Linux. But the truth is, while I know how
to tweak filter knobs and stuff on a real synth to get the sound
I want, I've never been able to recreate that sort of Moog or
Arp sound that is the whole reason I use simulations of analog
synths in the first place.
Some of the sounds created by Matthias came *very* close to e.g.
to the classical Moog sounds. One of the key factors IIRC was
the use of the high-pass filter plugin module, which was also my
last contribution to AMS.
On of the last things that Matthias added to AMS was a user-defined
view of a subset of the zillions of controls that you can have in
a complex patch, and a preset system referring only to the controls
present in that view. This allows you to create a simple interface
to a patch and forget about the signal flow window and its modules.
Unfortunately that system - practical as it is - was added without
much consideration for the consequences of how it was implemented,
and so it became one of the obstacles to a much needed reworking
of AMS.
--
FA
Lascia la spina, cogli la rosa.
7:18 p.m.
Fons Adriaensen <fons(a)kokkinizita.net> writes:
do you think there is a place for a softsynth that
would be modular
but with a fixed set of modules, everyhing controlled from one
window, no patch cables, only 'hardware controls' such as sliders
and switches, each one assignable to MIDI, and of course
uncompromising audio quality ?
This is more an interface. I think it's really bad if the synth
interface is not separated from the core. Projects like smash and
build tools like khagan are the right way to design such interfaces
while still not excluding power users who wants to dig deeper.
Many people feel comfortable with knobs (even though knobs are the
most non intuitive controller on a GUI, in my opinion) and it would
present a familiar interface.
You could make 10 such interfaces for some sounds and the user
familiar with such interfaces would be happy;).
The belt wheel controller on ardour is a very nice controller, btw;)
--
Esben Stien is b0ef@e s a
http://www. s t n m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@ n n
7:59 p.m.
On Mon, Jan 08, 2007 at 03:06:37AM +0100, Esben Stien wrote:
Fons Adriaensen <fons(a)kokkinizita.net> writes:
If you meant 'an interface issue' I disagree. The impact of the
suggested restrictions goes much deeper than only the interface.
do you think there is a place for a softsynth
that would be modular
but with a fixed set of modules, everyhing controlled from one
window, no patch cables, only 'hardware controls' such as sliders
and switches, each one assignable to MIDI, and of course
uncompromising audio quality ?
This is more an interface. I think it's really bad if the synth
interface is not separated from the core.
They have to be in separate threads or processes of course.
But in the case I proposed the interface would directly reflect
the nature of the core and would not try to hide or generalise it,
so no further separation would be required or even wanted. It's a
very specific core, and the idea is to have an interface that fits
very closely to it. This allows to do things in the interface that
would be very hard in a more abstracted approach.
Projects like smash and
build tools like khagan are the right way to design such interfaces
while still not excluding power users who wants to dig deeper.
If you want a separate interface OSC is the way to do it. The
tools used don't matter. But there is no 'deeper' in this case
- that's the whole point of it.
The belt wheel controller on ardour is a very nice
controller, btw;)
True, and it's one I would use for such a project.
--
FA
Lascia la spina, cogli la rosa.
12:29 p.m.
Dave Phillips wrote:
You're right, and the dropping of well started projects in need of more
work (like ams and zynaddsubfx) is part of this. But perhaps the reason
for such problems are to be found near the nature of open source
software: People are mainly motivated by 1) what they think is fun, 2)
what they need and 3) what can promote their ego.
Maintaining, let alone takeover of, an established project in heavy need
for an overhaul doesn't really do much for any of the above.
I often had the thought "why don't we (linux audio users) collect a
stack of money and throw them at projects that we feel needs work", I'm
personally thinking about zyn, specimen and ams. I have the feeling that
this wouldn't be considered "fair play", but apparently letting the
forces of open source software and Christmas spirit doesn't always give
us the software we like/need/hoped/hope.
<snip>
I'm interested in helping with
bringing it to a state where it's a bit more usable...
A worthy and laudable interest. I'm dismayed by the slowdown re:
development of native Linux synths, and I see more projects languishing
instead of moving forward. Good stuff is out there, but it seems to
me that our choices are dwindling.
I share your view!
Don't get me wrong, I like what we have. I just
want more. :)
I don't want more, rather I want continuous development of the excellent
things we have, to make them better in stability, usability and features.
--
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, 07 Jan 2007 13:27:11 +0100
Atte André Jensen <atte.jensen(a)gmail.com> wrote:
Hi
I just rediscovered ams. What a nice synth! Actually I started
implementing some of the few things I feel is missing. However it seems
to me that nobody's using, at least the mailing lists are totally dead. So:
1) Anyone using it?
Had just a brief look at it.
2) If not, why? Don't need/understand this type of
synth? Use something
else (what) instead? Technical reasons/limitations?
It gets nice results but seems a *lot* of effort to get them. Also I'm
used to fully polyphonic synths (both hardware & software).
3) If you ever tried what did you love about it and
what did you hate?
Did you find user friendly? Did it perform well?
Not at all user friendly - couldn't find any help information.
4) To rephrase 2): If the project was resurrected,
what would it take
for *you* to start using it.
Doubtful that I'd be interested actually.
5) Anyone (other than me) looked inside the code and
interested in
discussing certain aspects of that? Maybe even a joint effort to repair
the quirks in ams?
Scary stuff!
Finally let make it clear that I don't have the
time or knowledge to
take over development of ams. But I'm interested in helping with
bringing it to a state where it's a bit more usable...
Kudos to you if you do, but personally I'd be more interested in (what
you're already doing with) ZynAddSubFX :)
--
Will J G
12:03 p.m.
Folderol wrote:
This wasn't the purpose of this thread, but for the record there are
included example patches +
http://alsamodular.sourceforge.net/alsamodularsynth_doc.html
Fair enough!
Well, first ams and zyn are quite different and would make a great
combo. Secondly it seems that zyn has problems that go so deep a
complete rewrite is needed for it to perform well in a jack/low
latency/realtime environment. And such a rewrite is totally out of my
league + the people that IMO could take on such a task choose not to,
probably because of the size of the task...
This means that I (put harshly) have to consider zyn dying, whereas to
me ams is more in hibernation...
Anyways, thanks for your thoughts!
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
It gets nice results but seems a *lot* of effort to
get them.
If you're not used to modular synthesis, yes. Plus don't have a stock of
presets to load...
Also I'm
used to fully polyphonic synths (both hardware & software).
For the record ams is polyphonic, use -p when you start the program
3) If you ever
tried what did you love about it and what did you hate?
Did you find user friendly? Did it perform well?
Not at all user friendly - couldn't find any help information. 4) To rephrase
2): If the project was resurrected, what would it take
for *you* to start using it.
Doubtful that I'd be interested actually.
<snip>I'm interested in helping with
bringing it to a state where it's a bit more usable...
Kudos to you if you do, but personally I'd be more interested in (what
you're already doing with) ZynAddSubFX :) 
10 Jan
10 Jan
5:39 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Jan 07, 2007 at 06:02:01PM +0100, Atte Andr?? Jensen wrote:
I am using it, and now that I know how to make it polyphonic I will be using it a *lot*
more.
What are the things I'd like to see?
1) Standard keybindings for Load(Open?)/Save/Exit
2) Some way to have multiple patches going simultaneously, and to switch them via MIDI
program changes.
3) Some way to quickly disconnect a module and eliminate all its connections, without
right-clicking on each connection and then the module itself.
4) Did I mention that the right-clicking makes me crazy sometimes. Between AMS and
Rezound I've had more than enough right-clicking. Left clicks would be nicer IMHO,
like Om.
5) The ability to separate the sound engine from the GUI, like Om does.
6) I haven't figured out how to connect the velocity to, say, the attack time of an
envelope. It may be possible already and I just don't know how to do it.
7) Oh, and if I don't have a particular LADSPA module present on my system, it'd
be nice if AMS tried to at least connect the modules that *are* present (I believe Om does
this correctly), instead of just giving up and connecting nothing at all.
BTW, I have a dream of taking something like Om/Ingen, or a headless client/server version
of AMS, and running it on a Linksys box with OpenWRT and a USB audio interface-- connected
to a USB keyboard like the Keystation, and playing live with it. A $100 modular
synthesizer module that fits in your pocket.... that'd rule...
Folderol wrote:
No F'in way.... [looks at man page]... wow, you're right! Dunno how I missed that
when I first read the docs; must have een on info overload mode at the time.
OK now I'm making AMS my main synth. I really like AMS, but what has stopped me from
using it more has been what I thought was a lack of polyphony. With "--poly 6" I
can get some killer pads going here.
It gets nice results but seems a *lot* of effort
to get them.
If you're not used to modular synthesis, yes. Plus don't have a stock of
presets to load...
Also I'm
used to fully polyphonic synths (both hardware & software).
For the record ams is polyphonic, use -p when you start the program
>>3) If you ever tried what did you love about it and what did you hate?
>>Did you find user friendly? Did it perform well?
What I love about it is that it sounds a lot like an old modular synth! Works like one
too, with control voltage.
What I also love about it is that every little thing is MIDI controllable. I like to tweak
knobs, and I've got a couple dozen of them on my M-Audio Keystation Pro 88. The MIDI
assignment is pretty straightforward: put it in "follow MIDI mode", tweak a
knob, then assign it to some parameter or another. Other software synths drive me crazy
when I have to sit there with the mouse trying to grab a little circle on a screen...
There are other nice things like the phaser being integrated in as a module. The sample
patches and tutorial are great. It seems like a very deep package.
Not at all user friendly - couldn't find any help information.
This wasn't the purpose of this thread, but for the record there are
included example patches +
http://alsamodular.sourceforge.net/alsamodularsynth_doc.html
>>4) To rephrase 2): If the project was resurrected, what would it take
>>for *you* to start using it.
>
>Doubtful that I'd be interested actually.
Fair enough!
Well, first ams and zyn are quite different and would make a great
combo. Secondly it seems that zyn has problems that go so deep a
complete rewrite is needed for it to perform well in a jack/low
latency/realtime environment. And such a rewrite is totally out of my
league + the people that IMO could take on such a task choose not to,
probably because of the size of the task...
Ah, thanks! That'd explain why one of my songs that has a Zyn pad in it was causing
massive Xruns. I will avoid Zyn from here on.
<snip>I'm interested in helping with
bringing it to a state where it's a bit more usable...
Kudos to you if you do, but personally I'd be more interested in (what
you're already doing with) ZynAddSubFX :)
This means that I (put harshly) have to consider zyn dying, whereas to
me ams is more in hibernation...
And I hope it comes out of hibernation soon...
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFpMJGe8HF+6xeOIcRAvo7AKCnkxojp/cHrZlNqD4ZQUkz66lXEQCgmoag
LX/yskKBygMspMtnSoSMFB4=
=0uij
-----END PGP SIGNATURE-----
9:10 a.m.
On Wed, Jan 10, 2007 at 02:39:02AM -0800, Ken Restivo wrote:
BTW, I have a dream of taking something like Om/Ingen,
or a headless client/server version of AMS, and running it on a Linksys box with OpenWRT
and a USB audio interface-- connected to a USB keyboard like the Keystation, and playing
live with it. A $100 modular synthesizer module that fits in your pocket.... that'd
rule...
[plug]
Well, it's a little bit more than $100, but this is a picture of a
synthesizer-in-your-pocket connected to some midi controllers, which
could easily be a midi keyboard instead. (gp2xPd running on a gp2x)
<http://www.flickr.com/photos/tschuktschuk/203837189/in/set-72157594220067743/>
Thanks to Jay for this image!
[/plug]
Best,
Chris.
-------------------
chris(a)mccormick.cx
http://mccormick.cx
9:28 a.m.
<http://www.flickr.com/photos/tschuktschuk/203837189/in/set-72157594220067743/>
Yup .. and its a lovely little environment for audio hacking too, I
might add .. and is bound to get better as we get gadget_audio,
gadget_midi, MidiShare and rlyehs' minilib all working in such a way
as to provide us a 'totally integrated' hardware platform for
synth/plugin development ..
--
;
Jay Vaughan
1:23 p.m.
Jay Vaughan wrote:
Yup .. and its a lovely little environment for audio
hacking too, I
might add .. and is bound to get better as we get gadget_audio,
gadget_midi, MidiShare and rlyehs' minilib all working in such a way as
to provide us a 'totally integrated' hardware platform for synth/plugin
development ..
Sounds interresting! Who are "we", what's the processor power like, is
it DIY, and where can I read more about it?
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
3:53 p.m.
Yup .. and its
a lovely little environment for audio hacking too, I
might add .. and is bound to get better as we get gadget_audio,
gadget_midi, MidiShare and rlyehs' minilib all working in such a
way as to provide us a 'totally integrated' hardware platform for
synth/plugin development ..
Sounds interresting! Who are "we", what's
the processor power like,
is it DIY, and where can I read more about it?
4:24 p.m.
Jay Vaughan wrote:
the
processor power is what you'd expect out of a dual-core ARM running at
anywhere from 200mhz -> 275mhz
In all it sounds very interesting. However 275mhz is a bit too slow for
me. I was hoping to run rt audio generating apps, esp csound...
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
5:24 p.m.
On Wed, 10 Jan 2007 22:12:52 +0100
Atte André Jensen <atte.jensen(a)gmail.com> wrote:
Jay Vaughan wrote:
You are not comparing like for like. ARM processors raw number-crunch in
FAR fewer clock cycles than x86 architecture. Typically 3x (I might
be a little out of date with those figures).
--
Will J G
the
processor power is what you'd expect out of a dual-core ARM running at
anywhere from 200mhz -> 275mhz
In all it sounds very interesting. However 275mhz is a bit too slow for
me. I was hoping to run rt audio generating apps, esp csound...
5:41 p.m.
Folderol wrote:
You are not comparing like for like. ARM processors
raw number-crunch in
FAR fewer clock cycles than x86 architecture. Typically 3x (I might
be a little out of date with those figures).
Hmmm, so you're saying it should compare to something like a dual 900mhz
machine when running csound (or ams or zyn)?
That might be enough...
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
11 Jan
11 Jan
3:26 a.m.
Folderol wrote:
You are not comparing like for like. ARM processors
raw number-crunch in
FAR fewer clock cycles than x86 architecture. Typically 3x (I might
be a little out of date with those figures).
And all that extra number cruch will be chewed up by the fact that
GCC produced much less optimised ARM code than it does x86 code.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Just look at the development within Europe, where the number of Muslims is
expanding like mosquitoes. Every Western woman in the EU is producing an average
of 1.4 children. Every Muslim woman in the same countries is producing 3.5
children. Our way of thinking will prove more powerful than yours."
-- Norwegian imam Mullah Krekar to the Oslo newspaper Dagbladet in 2006
4:59 a.m.
Jay Vaughan wrote:
At 19:26 +1100 11/1/07, Erik de Castro Lopo wrote:
I heard this first hand (about gcc3.3) from two developers who work
on the L4 microkernel on ARM. These people know about low level C
code and ARM assembler.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"You'll never go broke underestimating the intelligence of the
American public." -- P.T. Barnum
And all that extra number cruch will be chewed up
by the fact that
GCC produced much less optimised ARM code than it does x86 code.
Not really true.
5:12 a.m.
Not really
true.
I heard this first hand (about gcc3.3) from two developers who work
on the L4 microkernel on ARM. These people know about low level C
code and ARM assembler.
5:46 a.m.
Jay Vaughan wrote:
I also work in low level C code, and ARM assembler,
and have
extensive experience working with gcc, F/OSS tools, distributions,
and the Linux kernel, since the day of the minix-list post..
In the #gp2xdev scene, we have pressed into use every gcc version
from 2.95.3 to 4.2 in order to get better, faster, leaner ARM code on
the GP2X (these are game coders who don't mind writing their own OS
if it pushes pixels a little faster) .. For sure, there are things
you can do with gcc on ARM that will result in fat, bloated, un-fast
code.. just as there are things you can do with it that will run
lean, fast and mean.
Your generalization is negatively bias'ed on the basis of second hand
details and in my opinion should not be parleyed without direct
experience. Ask your pals about gcc 4.1.
Ok, your direct experience trumps mine which admittedly about 3
years old. I'll quiz my contacts on their opinion on gcc-4.2 on
ARM.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Diana West for President of the United States
http://www.washtimes.com/op-ed/20060817-091447-7758r.htm
http://www.washtimes.com/op-ed/20060824-084015-5082r.htm
5:55 a.m.
Ok, your direct experience trumps mine which admittedly
about 3
years old. I'll quiz my contacts on their opinion on gcc-4.2 on
ARM.
Erik
Please let us hear what they have to say about it .. I think there's
a lot of generally negative critical opinion about the efficacy of
ARM for processing-related tasks, and the facts of the matter are
that an ARM-based machine can do some kick-ass things in the audio
world .. its not a matter of it needing to be 'the fastest', but
'fast enough', and especially if you consider the price and
availability of ARM machinery, there's not much to be said about it:
it kicks ass.
Soon as I finish gadget_audio for the GP2X, for example, I'm going to
have 3 new portable effects plugins/synthesis engines sitting on my
desk for use with my DAW .. for less than half the price of a
comparable turnkey system.
--
;
Jay Vaughan
10 Jan
10 Jan
7:50 p.m.
On Wed, Jan 10, 2007 at 10:12:52PM +0100, Atte André Jensen wrote:
Jay Vaughan wrote:
Gp2xPd is a rt audio generating app. I've used it live already twice.
Best,
Chris.
-------------------
chris(a)mccormick.cx
http://mccormick.cx
the
processor power is what you'd expect out of a dual-core ARM running at
anywhere from 200mhz -> 275mhz
In all it sounds very interesting. However 275mhz is a bit too slow for
me. I was hoping to run rt audio generating apps, esp csound...
11 Jan
11 Jan
4:11 a.m.
New subject: GP2X as a RealTime Audio generating device (was Re: [linux-audio-user] status of ams)
In all it
sounds very interesting. However 275mhz is a bit too slow for
me. I was hoping to run rt audio generating apps, esp csound...
Gp2xPd is a rt
audio generating app. I've used it live already twice.
5:47 p.m.
New subject: GP2X as a RealTime Audio generating device (was Re: [linux-audio-user] status of ams)
Jay Vaughan wrote:
Indeed, there is plenty of oomph in the GP2X for
generating live audio
.. its a softsynths paradise, even ..
Ok, I'm currently running csound live on a P4 mobile 1.6GHz. Let's call
this soft synth index 100. What would you estimate the index of GP2X to
be? Just a serious, guess, I'm not gonna come after you if your wrong :-)
Secondly, would there be any problems (if so which and could they be
solved) in getting 1) csound, 2) ams and 3) zynadsubfx running on these
things?
atte@ajstrup:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 9
model name : Intel(R) Pentium(R) M processor 1600MHz
stepping : 5
cpu MHz : 1600.000
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov
pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips : 3190.61
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
6:28 p.m.
New subject: GP2X as a RealTime Audio generating device (was Re: [linux-audio-user] status of ams)
Ok, I'm currently running csound live on a P4
mobile 1.6GHz. Let's
call this soft synth index 100. What would you estimate the index of
GP2X to be? Just a serious, guess, I'm not gonna come after you if
your wrong :-)
I'd give it between 40 - 60, depending on what you're doing in CSound ..
Secondly, would there be any problems (if so which and
could they be
solved) in getting 1) csound, 2) ams and 3) zynadsubfx running on
these things?
CSound: a cynch. ams or zynadsubfx, a bit trickier as it has GUI
requirements: the GP2X does not have X, or a Window manager (though
these have been ported..)
Any softsynth that supports a 'server' mode and a 'GUI command app'
separation can be ported and expected to run 'okay' on the GP2X .. I
know of a synth author who has his text-mode "daemon-style" synth
engine running in the background on the GP2X in such a way that it is
controlled with OSC messages being fired by an SDL app in the
foreground, for example .. or you can use gp2xPd for the interface to
such a synth daemon, also.
--
;
Jay Vaughan
12 Jan
12 Jan
4:14 p.m.
New subject: GP2X as a RealTime Audio generating device (was Re: [linux-audio-user] status of ams)
Jay Vaughan wrote:
Ok you got my attention!
I read that it's a 2.4 kernel, right? From what I know (I run 2.6) 2.4
has really poor realtime performance out of the box. Do you know:
1) What patches have been applied to the kernel in gp2x?
2) How difficult it would be to replace the kernel with a recent 2.6
3) what latencies have you been able to achieve (with the break-out box
for audio) with the supplied kernel? I'm not interested in hypothetical
performance but real world examples.
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
Ok, I'm
currently running csound live on a P4 mobile 1.6GHz. Let's
call this soft synth index 100. What would you estimate the index of
GP2X to be? Just a serious, guess, I'm not gonna come after you if
your wrong :-)
I'd give it between 40 - 60, depending on what you're doing in CSound ..
Secondly, would there be any problems (if so
which and could they be
solved) in getting 1) csound, 2) ams and 3) zynadsubfx running on
these things?
CSound: a cynch. 
10 Jan
10 Jan
6:13 p.m.
Jay Vaughan wrote:
<snip> the processor power is what you'd
expect out of a dual-core ARM
running at anywhere from 200mhz -> 275mhz (its an overclockers
delight) with 64megs of RAM, the device itself is made by GamePark
Holdings (http://gbax.com/) and you can read more about it here:
I must interject
here.
The MagicEyes Digital Co. MMSP2 System on Chip (SoC) does have two
processors - an ARM 920 and an ARM 940.
Neither (as licensed by ARM) has the logic required to consider this a
multi-core chip (no cache coherency logic, bus snooping etc). An SMP
kernel should still only find one CPU though the other could be used as
a _very_ smart peripheral.
Note that an ARM 940 does not (if memory serves) have any MMU or even an
MPU (you could of course run uClinux on that though).
I also have to declare bias in that I work for one of the parties
mentioned above, and that I am speaking purely for myself.
cheers
R
11 Jan
11 Jan
4 a.m.
New subject: GP2X, ARM, MagicEyes .. was Re: [linux-audio-user] status of ams
Neither (as licensed by ARM) has the logic required to
consider this
a multi-core chip (no cache coherency logic, bus snooping etc). An
Thats why I said dual-core, but you're correct in indicating that
this could be a point of confusion. The GP2X has two ARM processors
(on the same core), one of them is for Linux and the other is for
whatever you feel like programming it to do .. Linux acts as the Host
operating system, the 2nd CPU sits idle until its given code to run ..
SMP kernel should still only find one CPU though the
other could be
used as a _very_ smart peripheral.
From the standpoint of "Multi-processing", Linux doesn't know about
the second CPU on the GP2X at all - its ignorant of the 2nd CPU in
any sense other than seeing it as a device and giving you a way to
get code onto it/share memory with it - you have to load the 2nd CPU
with your own code and run your own sub-program.
GPH ship the GP2X with a video codec sub-program for the internal
movie-player; others have built an audio processing sub-program, an
OpenGL software-renderer (which is already getting use in ports),
some games put their AI on the 2nd CPU, etc.
With the independent work of the #gp2xdev community, its quite easy
to write code for the 2nd CPU and run it alongside your Linux app ..
Note that an ARM 940 does not (if memory serves) have
any MMU or
even an MPU (you could of course run uClinux on that though).
You don't need either of those things to write smart code for the 2nd CPU ..
I also have to declare bias in that I work for one of
the parties
mentioned above, and that I am speaking purely for myself.
1. GamePark
2. MagicEyes
3. ARM, Inc?
--
;
Jay Vaughan
10 Jan
10 Jan
7:45 p.m.
Hi,
On Wed, 10 Jan 2007, Jay Vaughan wrote:
We are the GP2X hackers, mostly collected around
#gp2xdev on EFNet, the
processor power is what you'd expect out of a dual-core ARM running at
anywhere from 200mhz -> 275mhz (its an overclockers delight) with 64megs of
RAM, the device itself is made by GamePark Holdings (http://gbax.com/) and
you can read more about it here:
btw, have you or anyone else on the list taken a look at how these apps
run on Nokia 770, or the new N800...?
- http://arstechnica.com/news.ars/post/20070109-8575.html
- http://www.linux-watch.com/news/NS7056717365.html
- http://www.engadget.com/2007/01/06/nokia-n800-specs/
- http://www.maemo.org , http://europe.nokia.com/A4305063
GNU/Linux/Debian/Gnome based, somewhat more powerful ARM cpu, more RAM.
Some hacking is needed as well to get USB host mode working (the device
can't supply power to slave USB devs)... but you do have wifi, bt2.0, a
nice 4.1" screen running X, sd/mmc slot, ... Not as cheap as gp2x is
though...
--
links, my public keys, etc at http://eca.cx/kv
11 Jan
11 Jan
4:08 a.m.
New subject: GP2X, ARM, Nokia .. was Re: [linux-audio-user] status of ams
btw, have you or anyone else on the list taken a look
at how these
apps run on Nokia 770, or the new N800...?
Nope, but if I had an N800 available to me I'm sure it'd be a quick
port target.
The platform is similar enough ..
GNU/Linux/Debian/Gnome based, somewhat more powerful
ARM cpu, more
RAM.
Try not to discount the GP2X' second ARM core, which is quite a fun
hack, and also remember that the GP2X' Linux firmware is far less
bloated than that of Nokia (almost painfully so), in order to provide
a much lighter, smaller, faster footprint for game developers ..
Not to discount the Nokia devices, nor any of the thousands of
ARM-based/Linux-compatible handheld, portable computing systems,
currently flooding the market... the point is, the GP2X is available,
cheap (circa $150), light, battery-powered, and already building up a
huge suite of fun applications worth the effort to get involved in ..
and I think the GP2X is far more hackable than Nokia would be
comfortable people doing with the N770/N800 (i.e. there are already
full firmware replacements out there for the GP2X, including quite a
few non-Linux ones..)
Some hacking is needed as well to get USB host mode
working
All thats needed with the GP2X is a cable/docking station, and these
are easy to obtain. Host mode works like you'd expect it to work on
a Linux-based system ..
(the device can't supply power to slave USB
devs)... but you do have
wifi, bt2.0, a nice 4.1" screen running X, sd/mmc slot, ...
TV Output?
Not as cheap as gp2x is though...
Definitely not. I've got 3 GP2X's for the price I would've had to
pay for a single N800 .. Still, exciting times for all Linux/ARM
hackers, and even more exciting times for those of us pressing such
systems into audio processing uses ..
{3 GP2X's running g_midi/g_audio [total integration] == cheap and
effective sub-effects processors for the DAW..}
--
;
Jay Vaughan
10 Jan
10 Jan
9:39 a.m.
Ken Restivo wrote:
I am using it, and now that I know how to make it
polyphonic I will
be using it a *lot* more.
I'm glad you discovered --poly :-)
What are the things I'd like to see? 1) Standard
keybindings for
Load(Open?)/Save/Exit
Should be easy...
5) The ability to separate the sound engine from the
GUI, like Om
does.
Well at least you can use -n (or --nogui) for starting without the gui.
7) Oh, and if I don't have a particular LADSPA
module present on my
system, it'd be nice if AMS tried to at least connect the modules
that *are* present (I believe Om does this correctly), instead of
just giving up and connecting nothing at all
As far as I remember Om also gave up on this...
BTW, I have a dream of taking something like Om/Ingen,
or a headless
client/server version of AMS, and running it on a Linksys box with
OpenWRT and a USB audio interface-- connected to a USB keyboard like
the Keystation, and playing live with it. A $100 modular synthesizer
module that fits in your pocket.... that'd rule...
We all have different dream. I once dreamed of putting a ultra flexible
modular synth setup together in csound and run it from live on a laptop
controlled by 3 usb keyboards. Now this is something I've done routinely
for over 3 years...
And I hope it comes out of hibernation soon...
That would be nice...
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
2:56 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Jan 10, 2007 at 03:39:48PM +0100, Atte Andr? Jensen wrote:
Ken Restivo wrote:
Heh, well I got to excited too soon. Running some of the more complex modules like Dynamic
Waves with --poly 6 causes my machine (1.66Ghz Core Duo) to lock up with 100% CPU usage.
Also, I have to remember to turn off Follow MIDI mode before doing any kind of recording
or performance, because if I don't, AMS segfaults.
Also, running monophonic patches like the Bass patches with --poly mode causes some
outragous distortion. It's like all voices are stacking on top of each other, and
raising the level so high that even with the AGC inside the PCM output module, it still
clips like crazy.
But, hey, nothing's perfect, and it still sounds bitchen. Much fun has been had, and
more will be soon.
I suppose I should play with Om some more too.
- -ken
I am using it, and now that I know how to make it
polyphonic I will
be using it a *lot* more.
I'm glad you discovered --poly :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFpULse8HF+6xeOIcRApYYAKC/Rj/4Sz2mhzqm8o1rRoOJpX7fDgCg9iDI
Y++o1QyY3NMoFWp/7JlcS8Y=
=13yY
-----END PGP SIGNATURE-----
7 Jan
7 Jan
1:09 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Atte André Jensen schrieb:
Hi
I just rediscovered ams. What a nice synth!
1) Anyone using it?
Yes!!! I use it a lot both as a synth and as a LADSPA-FX-host. The
Debian-Binary I use on Ubuntu works flawless and produces sounds I
cannot reproduce with any other synth on Linux.
2) If not, why? Don't need/understand this type of synth? Use something
else (what) instead? Technical reasons/limitations?
If one wants to use it polyphonic, it can easily crack any CPU and the
usage is somewhat a matter of getting used to it. But since the synth
works stable (much more stable than OM), this is worth the effort.
3) If you ever tried what did you love about it and what did you hate?
Did you find user friendly? Did it perform well?
as said before: once you find out, how the interface ticks, it discovers
itself as very userfriendly in terms of how much one have to learn
before the fun begins. In that domain only Zynadd ist up to ams'
standards. It took me about 12 h or so until my first own ams-patch
played something constructive. I have tried to make PD play anything at
all for abot 40-50 h and still cannot make it do anything usable.
Another thing I found to be absolutely outstanding is te maximum
flexibility regarding the support for midi-controllers, ams has a simple
list, in wich an active midicontroller shows up, as it send something,
than you can link this controller to virtually any parameter of the
patch - I dont know any other easily usable synth on Linux, that offers
such...
4) To rephrase 2): If the project was resurrected,
what would it take
for *you* to start using it.
I use it, I will be just gratefull, that I can continue and praise you
all over the net ;-) ;-)
Finally let make it clear that I don't have the
time or knowledge to
take over development of ams. But I'm interested in helping with
bringing it to a state where it's a bit more usable...
Even if the actual state of ams is preserved and adapted to upcoming
developements, I would extremely appreciate it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFoTaK1Aecwva1SWMRAnJ9AJ0esEav4kGdCSjcawbSBJfwXvmO7gCeOUak
EbL90WUqqFWKr0OFk2OAbpo=
=8xNH
-----END PGP SIGNATURE-----
2:13 p.m.
Hartmut Noack wrote:
I use it, I will be just gratefull, that I can
continue and praise you
all over the net ;-) ;-)
Ok, I get the message :-)
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
6565
days inactive
6570
days old
linux-audio-user@lists.linuxaudio.org
55 comments
21 participants
participants (21)
-
Atte André Jensen -
Chris McCormick -
Dave Griffiths -
Dave Phillips -
Erik de Castro Lopo -
Esben Stien -
Folderol -
Fons Adriaensen -
Frank Barknecht -
Georg Holzmann -
Hartmut Noack -
Jay Vaughan -
Kai Vehmanen -
Ken Restivo -
Lars Luthman -
Malte Steiner -
Nick Copeland -
Paul Winkler -
Rob -
rob -
Thorsten Wilms