Author |
Message |
robin746
Joined: Sep 02, 2007 Posts: 26 Location: Eire
|
Posted: Mon Sep 03, 2007 10:47 am Post subject:
three questions |
|
|
Here are some outstanding questions I'd like help on:
1. How can one subclass Ugen to write one's own generators? I see no examples in the docs.
2. Is it true ChucK has no serial I/O facilities?
3. The docs say that a new process is sporked, but no actual system process results (not on Win32 anyway). Is it accurate to call these "processes" in the usual definition of that term? Or are they OS threads? Or something different again? |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Mon Sep 03, 2007 4:06 pm Post subject:
|
|
|
1) I don't think you can because you can't define what happens if you ChucK values straight into a class instance. There are things in development to add Ugens.
2) I expect this quite soon, Ge was looking for a cross-platform library a while ago.
3) these "proceses" are running inside of the VM, they aren't "real" OS processes. Their main point is perhaps to avoid having to write the whole thing as one huge loop. I'd say they are "processes" in the informal sense of the word (strucures that do something), not in the OS-architecture sense. _________________ Kassen |
|
Back to top
|
|
|
robin746
Joined: Sep 02, 2007 Posts: 26 Location: Eire
|
Posted: Mon Sep 03, 2007 4:41 pm Post subject:
|
|
|
Kassen wrote: | 1) I don't think you can because you can't define what happens if you ChucK values straight into a class instance. There are things in development to add Ugens. |
This means there's no way to tie into the whole "code as patch-cord metaphor" that makes the signal flow so appealing. Annoying.
Kassen wrote: | 2) I expect this quite soon, Ge was looking for a cross-platform library a while ago. |
This is pretty well essential to interface ChucK with Arduino etc. And I imagine it's pretty darned simple. Hope to see it soon!
-- robin |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Mon Sep 03, 2007 5:17 pm Post subject:
|
|
|
robin746 wrote: |
This means there's no way to tie into the whole "code as patch-cord metaphor" that makes the signal flow so appealing. Annoying.
|
I think that's a bit of a exageration. Right now you can't create your own Ugens as such in ChucK itself but you can get very close. You definately *can* treat audio according to any function you can mathematically express and you can also generate any wave you can mathematically express, it just won't be a "Ugen", I still see plenty of room for using code as a analogy for patch-cords. A good place to see a example of this kind of thing would be in the "distortion" topic on this board.
If it absolutely has to be a Ugen the only way right now will be writing it in C/C++, adding it to the ChucK source and recompiling. Some people have done that. _________________ Kassen |
|
Back to top
|
|
|
robin746
Joined: Sep 02, 2007 Posts: 26 Location: Eire
|
Posted: Tue Sep 04, 2007 2:48 am Post subject:
|
|
|
Kassen wrote: | I think that's a bit of a exageration. Right now you can't create your own Ugens as such in ChucK itself but you can get very close. |
I am not meaning to exaggerate, but wish to express succinctly what I am still learning. I managed to put the following together from a look at the thread you mentioned:
Code: |
class Fader {
// how to fake a gain-control Ugen
// signal flow
Gain in;
Gain out;
in => out;
// something to control
fun void gain(float i) {
i => out.gain;
}
}
// patch in class *almost* like ugen
Fader fader;
SinOsc s => fader.in;
fader.out => dac;
// now, try it
120.0 => s.freq;
2::second => now;
.1 => fader.gain;
120.0 => s.freq;
2::second => now;
|
This example illustrates the way of working around the fact ugens cannot be subclassed. It exploits the fact that the chuck operator is overloaded as assignment.
The core issue is that the input and output of the ugen cannot be referenced programmatically. It would be nice if this was (eventually) added to the language. I see no reason ugens should not be first-class objects.
-- robin |
|
Back to top
|
|
|
robin746
Joined: Sep 02, 2007 Posts: 26 Location: Eire
|
Posted: Tue Sep 04, 2007 3:01 am Post subject:
|
|
|
With a bit more looking I have discovered that what I propose is already planned for the language.
In the manual there is an empty section for Creating on the Unit Generators page.
Also, Ge Wang wrote last October:
Quote: | We've actually been planning something for
this very purpose. In short, one should be able to define a UGen and
use it as you would any other (e.g. in terms of =>), but you can't yet
in the current version. |
Personally I rate features like serial I/O and namespace support higher than this, but it's nice to know it is being investigated.
-- robin |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Tue Sep 04, 2007 6:23 am Post subject:
|
|
|
Completely correct on all counts, I'm sorry I wasn't more explicid about "not right now" meaning "we will in the future but I don't know when exactly".
"The List" (of things we will/should have) is quite large....
Now that I read it back I like Graham's idea of using "this.in" and "this.out" a lot but I'm not sure how that would work with, say;
class Player extends SndBuf; _________________ Kassen |
|
Back to top
|
|
|
robin746
Joined: Sep 02, 2007 Posts: 26 Location: Eire
|
Posted: Tue Sep 04, 2007 6:39 am Post subject:
|
|
|
I found such a list on the wiki, but it is out of date. Hard to tell for a commoner like me what has been implemented and what still awaits a future version. Some sort of timeline would be very nice.
-- robin |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Tue Sep 04, 2007 7:32 am Post subject:
|
|
|
You are right; the WiKi is a bit of a mess and uregently needs a cleaning if we want it to be usefull to new users -which should be the prime audience anyway.
As for a timeline; this would depend on developer time, I believe the developeers are already working very hard indeed in adition to lecturing and attending conferences so....
A rough outline of how I believe the planning is structured;
-attend to bad bugs (ones that crash the whole VM)
-some stuff.
-garbage collection
-maybe other stuff.
-things that depend on garbage collection (this one is a huge section and includes loads of neat and essential things)
-world dominantion
The bad news is that garbage-collection is apearing to be harder and more time-consuming then expected. _________________ Kassen |
|
Back to top
|
|
|
robin746
Joined: Sep 02, 2007 Posts: 26 Location: Eire
|
Posted: Tue Sep 04, 2007 2:23 pm Post subject:
|
|
|
Garbage collection can be like that.
My vote is for the very first "some stuff" to include integrating a serial I/O library since:
a) it'd open up the world of custom micro-controllers
b) it'll be brain-dead easy to programme -- no audio issues, just integrate an existing OS library
And namespaces.
-- robin |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Tue Sep 04, 2007 4:18 pm Post subject:
|
|
|
I'm afraid "namespaces" might be tied to "importing/including" and that that in turn would be prime canidate for belong to the "group of things that will create garbage".... :¬)
Serial I/O would be cool as I understand one can hook up leds pritty much directly to those and so my homebrew sequencer will no longer be behind in the "running leds" department so I'm in favour of that too. _________________ Kassen |
|
Back to top
|
|
|
|