Re: [ecasound] visecas install story

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] visecas install story
From: Jan Weil (jawebada_AT_mailbox.tu-berlin.de)
Date: Sun Feb 01 2004 - 11:51:29 EET


On Sat, 2004-01-31 at 19:13, Kai Vehmanen wrote:
> Today I tried Visecas for the first time.
>
> My machine is a mess/mixture of RH5->RH8, and I don't use Gnome at all, so
> the install process was, uhm, not as easy as it could be. But, but, now
> Visecas 0.3.5 is finally installed and running.
>
> What I had to do was:
> - install visecas-0.3.5
> - trying to run visecas produced errors about missing packages...
> - removed all libglade1 packages (conflicted with glade2 packages)
> - I had already gtk2 installed, so I could skip that
> - installed the following RH8 packages: libbonobo-2.0.0-4.i386.rpm
> GConf2-1.2.1-3.i386.rpm gail-*rpm libgnomecanvas-2.0.2-1.i386.rpm
> ORBit2-2.4.1-1.i386.rpm libart_lgpl-2.3.10-1.i386.rpm
> bonobo-activation-1.0.3-2.i386.rpm libglade2-2.0.0-2.i386.rpm
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
> libgnomecanvas-devel-2.0.2-1.i386.rpm libglade2-2.0.0-2.i386.rpm
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^
once should have been enough :P

> linc-0.5.2-2.i386.rpm libart_lgpl-devel-2.3.10-1.i386.rpm
> libglade2-devel-2.0.0-2.i386.rpm gnome-libs-devel-1.4.1.2.90-22.i386.rpm
> gnome-libs-1.4.1.2.90-22.i386.rpm

Cool if you want to give GNOME a chance but for Visecas these are far
too many packages.
libglade2 + devel should have sufficed (since gtk2 is already present).
Visecas does not depend on GNOME as a whole but I guess you started with
a package which introduced a lot of dependencies.

> - got the "/ecasound.rb:135:in `command': lost synchronisation to
> ecasound subprocess" error, so I edited the file
> "lib/ruby/site_ruby/1.8/visecas/ecasound.rb" and changed TIMEOUT
> to 60

Hmmm :(
What is your impression, Kai? Which value would have been high enough
for your system?
The longer I look at this problem the more I think that it is due to an
internal problem of Ruby's pipes.
The thing is that I am not able to reproduce this behaviour on my
system.
I tried to do some stress testing but I get rock solid parsing.
I'll assign 60 for the next release then but I feel this should not be.

>
> Some quick comments:
> - looks very nice! :)
> - I like the feature that visecas accepts all the same arguments
> as ecasound does; this makes switching between ecasound and
> visecas easy
>

When I started developing Visecas I was intending to visualize an
interactive Ecasound session.
But thinking of all the SuperEcasound feature's I'd like to implement
and especially Ecasound's controllers I feel that this approach does not
make sense.
TBH I already made a branch in CVS for the current version of Visecas.
There will be at least one more release featuring a properties dialog to
control Ecasound's general chainsetup options and a position dialog to
individually set audio objects positions.
But after that I'll probably concentrate on a slightly different concept
(maybe Supecas?).
I hope that eventually Visecas will also benefit from this.
I'd really like to see support for controllers somehow.

Thank you very much for your feedback.

Jan


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Feb 01 2004 - 11:49:16 EET