18 May
2005
18 May
'05
2:10 p.m.
i'm not subscribed to lau, please forward as appropriate.
On Wed, May 18, 2005 at 10:32:14AM -0400, Ivica Ico Bukvic wrote:
Now if I have:
Out.ar(out, SinOsc.ar(freq + 100, mul: 0.5))
This doesn't.
Naturally, one could always put something before this
statement to fix this, i.e.:
freq = freq + 100;
Out.ar(out, SinOsc.ar(freq, mul: 0.5))
But it is still interesting why the multiplication works
and addition doesn't.
works fine here. what value does freq have? what errors do
you get?
Also, I noticed that on one of your SCUM example
screenshots you are using .connect method to connect
something, yet I was unable to locate anything of value in
the documentation. I assume that this could be something
similar to the signal-slot idea in Qt and/or other Widget
languages (but obviously I may be completely off the
mark), so I was wondering if you could please provide an
example for that? I would really appreciate it!
SCUM did have a signal/slot mechanism, but it turned out to
be overkill.
Finally, while I am on the roll with questions :-), do
you
mind also mentioning what's the current status/roadmap of
SCUM in terms of supporting all stock Supercollider
widgets, as I noticed that the SCUM widgets use
non-standard names and in addition I am not sure whether
all widgets are as of yet supported, all of which, at
least in my experience, makes a number of sc examples
available on the net difficult if not impossible to run in
Linux.
in the upcoming release SCUM will evolve from an attempt to
provide the 'standard' SC view classes on linux to a
standalone, cross-platform server application. i agree it
was a questionable move to strive for compatibility with the
existing SC view classes in some areas, while doing things
differently in others. SCUM's heading towards total
incompatibility, so be patient :)
Please don't get me wrong, this is not to
criticize as I
am eternally grateful for SCUM, I am simply curious as to
what is the roadmap for the project.
there's no roadmap. work on SCUM is demand-driven, i.e. i
implement things if and when i need them, and most of the
time i don't need a gui. contributions (new view classes,
documentation) are welcome, though ...
<sk>