2 Mar
2007
2 Mar
'07
11:59 a.m.
I downloaded and read the code of AMS and see some possibilities to
improve its CPU load, it doesnt looked very optimized. Next week I could
do the coding and send the patches to Fons, whom I already contacted.
My approach I would descripe evolutionary, not revolutionary. Its like
opening a big expensive vintage Moog Modular for soldering. I dont want
to rewrite the soundengine, but like to help with optimizations and
improvements regarding usebility. The changes have to be done very
carefully and I will do an A/B test with the old AMS on the left and the
new AMS on the right ear.
Thats all I can offer...
Cheers,
Malte
--
Malte Steiner
media art + development
-www.block4.com-
next events:
2.3. DJ together with Xyramat at The Thing Party, Buttclub Hamburg
2 Mar
2 Mar
1:41 p.m.
Malte Steiner wrote:
I downloaded and read the code of AMS and see some
possibilities to
improve its CPU load, it doesnt looked very optimized.
That sounds very, very nice. As already mentioned, I would really like
this project to live on.
I semi-hacked in support for supplying client name on the command line.
I could send you a patch, if you're interested.
NB: AFAIK being able to specify a client name is critically if one wants
to reliably start more instances of ams. Without this each client gets a
random (or next free id) name which in racing conditions can be a
frustrating thing when connecting stuff...
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
2:27 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Mar 02, 2007 at 04:55:23PM +0100, Malte Steiner wrote:
I downloaded and read the code of AMS and see some
possibilities to
improve its CPU load, it doesnt looked very optimized. Next week I could
do the coding and send the patches to Fons, whom I already contacted.
My approach I would descripe evolutionary, not revolutionary. Its like
opening a big expensive vintage Moog Modular for soldering. I dont want
to rewrite the soundengine, but like to help with optimizations and
improvements regarding usebility. The changes have to be done very
carefully and I will do an A/B test with the old AMS on the left and the
new AMS on the right ear.
Thats all I can offer...
That would be great! I'm trying to move away from GUI's and to ChucK and maybe
SuperCollider or CSound for the future, but AMS gets some great sounds and I'll
continue to use it.
Is Fons or someone setting up a GNA/Savannah/something public repository so people can
submit patches and/or track SVN on it as it rises from its sleep?
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFF6Gr5e8HF+6xeOIcRArVwAJ9wn24itiXVnnJYmKfZSwzEYYUG6wCgySrv
ZMhxNZOiSm2a+CDL8U8bMa8=
=xQfo
-----END PGP SIGNATURE-----
11:38 p.m.
Hi,
That would be great! I'm trying to move away from
GUI's and to ChucK and maybe SuperCollider or CSound for the future, but AMS gets some
great sounds and I'll continue to use it.
Is Fons or someone setting up a GNA/Savannah/something public repository so people can
submit patches and/or track SVN on it as it rises from its sleep?
Actually I dont have a feedback from Fons yet, or maybe my spamfilters
killed it. Speed optimization is my first thing because I believe to see
some obvious stuff to improve but time will tell.
Second is an annoying dependency to something depricated QTLists or so
which at least made me necessary to google 10 minutes but I could
imagine that this turns off some newbies who dare to 'make' it and than
bang, no AMS for you. Autotools would be great too, its so simple to use
it but I have to look up how to do it, maybe its simple.
Than some improvements on the gui can be started. Thanks for the points
people mentionend already. An additional annoying thing is the right
click in the empty patch which brings up the color menue. And some
controls on objects are positionend suboptimal. For example the scope
has the trigger settings on another tab so you cant adjust while looking
on the screen and the results. Either I missed something or its just
suboptimal. These things cant be a big deal, but I would start the
optimizations first and if they really improve it I would declare it as
version 1.8.8, just to make it clear, AMS is back (although it never was
gone), wouldnt it be great to have a 1.8.8 for LAC?
Cheers,
Malte
--
Malte Steiner
media art + development
-www.block4.com-
3 Mar
3 Mar
11:39 a.m.
Hi Malte,
Actually I dont have a feedback from Fons yet, or
maybe my spamfilters
killed it. Speed optimization is my first thing because I believe to see
some obvious stuff to improve but time will tell.
Sorry for the delay - very busy days.
If you can revive this project that would be most welcome. I will have
very limited time to devote to AMS for the coming months.
So the best way to proceed will be that we (and any others interested)
discuss things to be done on the developers list. I will set up developer
access for you if you sent me your sourceforge login name.
Second is an annoying dependency to something
depricated QTLists or so
which at least made me necessary to google 10 minutes but I could
imagine that this turns off some newbies who dare to 'make' it and than
bang, no AMS for you.
There are QTLists everywhere in the code. I was never really involved
with the QT side of AMS - Matthias did all that - and I wouldn't dare
touching any of it.
I think the first things to be done are:
- Migration to the actual QT version.
- Removing the dependeny on fftw2 (either by porting the code to
fftw3 or, or by just removing the spectrum display - using jack
it's easy enough to set up a link to JAAA or JAPA or any other
external spectrum display. Maybe same for the scope.
- Efficiency improvements - there is lots of room for this in
some of the current dsp code.
Longer term changes:
- Remove the static ENV and MIDI objects. This will be a major task.
Once this is done we can have dynamic polyphony, and also multiple
independent polyphinic patches. I have some ideas on how this should
be done, but it will be a major rewrite and should be done only
after adapting everything to the current QT system.
- Reviewing the parameter view system so it gets better integrated
with the dynamic modularity. Currently modifiyng a patch having
a parameter view is a risky business.
--
FA
Lascia la spina, cogli la rosa.
12:49 p.m.
Hi all,
I would invite everyone interested in the future of AMS to join the
alsamodular-devel list, where all discussions on new developments
should take place. Too subscribe:
<https://lists.sourceforge.net/lists/listinfo/alsamodular-devel>.
I've added Malte as an AMS developer and editor for news, documentation
and screenshots. New releases on sourceforge will still require my
approval, but that should be a formality since all major changes
will be discussed first on the developers list and I will be actively
involved in that.
--
FA
Lascia la spina, cogli la rosa.
2 Mar
2 Mar
2:51 p.m.
Malte Steiner wrote:
I downloaded and read the code of AMS and see some
possibilities to
improve its CPU load, it doesnt looked very optimized. Next week I
could do the coding and send the patches to Fons, whom I already
contacted...
At some point something should be done to improve the GUI.
Best,
dp
3:13 p.m.
Dave Phillips wrote:
At some point something should be done to improve the
GUI.
EyeCandy, usability or both? If usability is involved, could you
summarize your main gripes?
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
3:39 p.m.
If usability is involved, could you
summarize your main gripes?
* remember open and save file paths
* autoappend extension to saved files
* allow opening files without extension, see 2 ;-)
* improved parameter view
Actually, the CPU load is one of the most important things to fix so it
can be used with a polyphony more than 8. And some day it needs to be
ported from Qt3 to 4, so separating the GUI from the engine would be
helpful (if it's not done yet).
Just my two cents,
ce
3 Mar
3 Mar
12:11 p.m.
Atte André Jensen wrote:
Dave Phillips wrote:
Both, though the eye candy certainly ought to be functional.
IMO "clunky" adequately describes the current GUI for this excellent synth.
It won't hurt my feelings if Linux devels take some time to investigate
the appearance of, say, a dozen or so best VSTi synths. I do find that
I'm often attracted by attractive things.
At some point something should be done to improve
the GUI.
EyeCandy, usability or both? If usability is involved, could you summarize your
main gripes?
Since AMS is a virtual patching modular synth, subpatching (a la Pd)
would be nice). Other niceties might include hidden wiring and a
configuration panel.
And yes, a real build system (autotools, scons, whatever) would be
helpful to those of us who still like to roll our own.
Best,
dp
6549
days inactive
6550
days old
linux-audio-user@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Atte André Jensen -
Christoph Eckert -
Dave Phillips -
Fons Adriaensen -
Ken Restivo -
Malte Steiner