Author |
Message |
larryreed
Joined: May 27, 2008 Posts: 18 Location: California
|
Posted: Tue Jun 03, 2008 11:47 pm Post subject:
forward references Subject description: Need a way to reference something I haven't loaded yet. |
|
|
I've been building a patch management system for my synth setup. It mostly works right now, which is great!
However, I've run into an issue where I need two classes to be able to reference each other. Since the programs have to be loaded in a specific order, I need to be able to create a reference in the class loaded earlier to a class that is not loaded until later.
In C++, this is easy because classes are linked after all the references are known. But I don't know how to do this in ChucK, or if it is possible.
Here's a (greatly simplified) example:
public class A {
int aa;
fun void SetMeUp(int x) {
x => aa;
}
while( true ) {
GetMidiInput();
if( midiInput == DoB )
B.SetHimUp(100);
}
}
public class B {
int bb;
fun void SetHimUp(int z) {
z => bb;
A.SetMeUp(z-2);
}
}
public class C {
fun void GetKeyboardCmd() {
if( cmd == S )
B.SetHimUp(50)
}
while( true ) {
GetKeyboardCmd();
}
}
chuck + A.ck B.ck C.ck
-->generates error B.DoSomething not defined in A.ck
As I said, in C++, I can do this because B.SetHimUp is defined as an interface, and linked later. Is there any analogous thing in Chuck?
In my system, essentially A is the basic operational loop, and B is a passive class that controls the operation of A in response to an outer level command loop, C. The problem is that A can receive a command externally (from a MIDI device) that I want to respond to as if it had been typed by the user in the command loop C.
The only other way I can think of for this to work is for A to define an event that C can respond to, and then A signals C, which calls B. Of course C has to then wait on either of two events. I'm not quite sure how to do that either.
But it'd be a lot simpler if I could just define a forward reference that is resolved when B is loaded.
-- Larry |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Jun 04, 2008 2:49 am Post subject:
Re: forward references Subject description: Need a way to reference something I haven't loaded yet. |
|
|
larryreed wrote: |
However, I've run into an issue where I need two classes to be able to reference each other. Since the programs have to be loaded in a specific order, I need to be able to create a reference in the class loaded earlier to a class that is not loaded until later.
|
You found another issue.
Yes; you can do this... as long as both classes are in a single file. So; it won't fly for public classes as there can only be one public class in a single file, currently.
We need proper include/import statements, I agree.
I think that this summer Ge is planning another wave of major features and this might be in there (we can hope....). Others have run into the same thing and it's one of the larger issues in using ChucK for larger projects. _________________ Kassen |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Jun 04, 2008 2:53 am Post subject:
Re: forward references Subject description: Need a way to reference something I haven't loaded yet. |
|
|
larryreed wrote: | It mostly works right now, which is great!
|
Yay! That's cool. I think your project is a entirely new field to ChucK in so that's nice and exciting. I would be interested, if you could spare the time, in hearing what you do like about ChucK.
It stands to reason that somebody with a C/C++ background would first like (most of) the syntax, then immediately miss a lot he's grown to come to expect. _________________ Kassen |
|
Back to top
|
|
|
larryreed
Joined: May 27, 2008 Posts: 18 Location: California
|
Posted: Wed Jun 04, 2008 11:52 am Post subject:
What I like about chuck... |
|
|
Yes, as C++ programmer, I do seem to want it to be like what I know.
The hardest thing for me to adapt to is the chuck operator. All my life, assignments have been of the form 'x gets y' ( x = y, x := y, x <y> variable'.
As to what I like about ChucK, I really like the ability to create a patch programmatically. One of my earliest programming projects when I was at CCRMA in the 70's (oops, showing my age...) was a visual editor for Music V. The idea was that you would patch unit generators together graphically by constructing a flowchart which would be compiled into a music program. I was not a CS student (you couldn't be as an undergrad in those days at Stanford), and I had only a couple of programming classes under my belt, so the project didn't really get very far. (Besides I was using SAIL, an ALGOL-W derived concoction never used anywhere but at the SU AI lab, but that's another story)
ChucK allows you do do much the same thing, albeit with programs instead of pictures. On the other hand, the visual approach limits the kinds of things you can do, and there was no concept of concrete timing. ChucK provides that in a real nice way.
I'm not familiar with other stuff, like SC, etc. So I don't know how comparable they are, or whether one of these others would be better for my purposes.
But ChucK provides a way to flexibly control my performance setup in a way I have never been able to do just with MIDI controllers. Moreover, once I have the hardware configuration stuff working, I can easily integrate the ChucK soft synth stuff to expand greatly my performance capabilities. The possibilities currently seem endless.
So at the moment, I'm really happy to play with it, and so far the results are very promising. Of course, reality has not really bitten yet...
-- Larry |
|
Back to top
|
|
|
larryreed
Joined: May 27, 2008 Posts: 18 Location: California
|
Posted: Wed Jun 04, 2008 11:59 am Post subject:
handling 2 events simultaneously |
|
|
If I want to try the event model, it would be necessary for me to construct a loop that waits on either of two events - a keyboard hit or a signal from the operational loop.
I'm not quite sure how this is accomplished. The standard way of doing an event loop is to chuck the event to now:
while( true ) {
e => now;
// do e-related stuff
}
But how do you chuck two events to now? For example, can I do this:
while( true ) {
e1 || e2 => now;
if( e1 )
// do e1 related stuff
if( e2 )
// do e2 related stuff
}
-- Larry |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Jun 04, 2008 2:04 pm Post subject:
|
|
|
There's been quite a bit of talk on the list about about waiting for multiple events.
Fortunately here it's fairly easy. I'm assuming you are sporking a shred that listens for the keyboard anyway, sorts keys and bases actions on them. So; we'd have two loops already being the keyboard shred and your main loop, right? And you want a third loop to wait for either a specific moment in the main loop or a key-press, say a space?
In that case it's really quite easy; you can have the main loop broadcast the a new event "foo" (say at the start of a musical section) and also have the keyboard-reading shred broadcast foo as soon as space is pressed. The third loop/shred would then be waiting for foo.
If you didn't already have a keyboard-reading shred you'll have to add it as you can't make the main loop broadcast a hid event.
It gets slightly trickier if the main loop should only broadcast in the case the keyboard reader hasn't done so already but you could do something like this;
Code: |
public class OneTimeEvent extends Event
{
int used;
fun void send()
{
if (!used)
{
true => used;
this.broadcast();
}
else
{
<<<"I've already done something and now I'm tired :¬)">>>;
}
}
}
OneTimeEvent foo;
fun void bar()
{
foo => now;
<<<"ping">>>;
}
spork ~bar();
me.yield();
repeat(3)
{
foo.send();
second => now;
} |
Note that when extending Event there is a bug and ChucK wants it to be defined before it's called (it needs to be higher up in the file if it's in the same file) or it won't properly inherit signal() and broadcast(). this is annoying but at least it's known and either fixed already or it should be soon-ish. _________________ Kassen |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Jun 04, 2008 2:25 pm Post subject:
Re: What I like about chuck... |
|
|
larryreed wrote: | Yes, as C++ programmer, I do seem to want it to be like what I know. |
Yeah, makes sense.
Quote: | The hardest thing for me to adapt to is the chuck operator. All my life, assignments have been of the form 'x gets y' ( x = y, x := y, x <y> variable'.
|
I know... But you have to admit it's nicely non-ambiguous. If you see some unknown language and read "x = y" it might mean x takes on y's value or y takes on x's value or we may need to test whether x already equals y or perhaps we expect a list of all scenarios in which X could equal y.....
Quote: | As to what I like about ChucK, I really like the ability to create a patch programmatically. One of my earliest programming projects when I was at CCRMA in the 70's (oops, showing my age...) |
I'd change avatars if my age were a secret ;¬)
Quote: | was a visual editor for Music V. The idea was that you would patch unit generators together graphically by constructing a flowchart which would be compiled into a music program. I was not a CS student (you couldn't be as an undergrad in those days at Stanford), and I had only a couple of programming classes under my belt, so the project didn't really get very far. (Besides I was using SAIL, an ALGOL-W derived concoction never used anywhere but at the SU AI lab, but that's another story) |
Still, that was the dawn of computer music and you got to see it, that's worth something as well. I think ChucK still has a lot of that "modular synthesis" architecture in it. Nice notes! _________________ Kassen |
|
Back to top
|
|
|
larryreed
Joined: May 27, 2008 Posts: 18 Location: California
|
Posted: Wed Jun 04, 2008 3:42 pm Post subject:
Waiting on multiple events |
|
|
Looks like you and I are thinking along the same lines. I just wanted to find out if there was a syntactical way of watching for several events at once.
Thanks, I think your solution will work for my needs.
-- Larry
BTW, my hair is blonde, not white... |
|
Back to top
|
|
|
Kassen
Janitor
Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Wed Jun 04, 2008 4:23 pm Post subject:
|
|
|
Oh, that's a shame. I'm 30 and slowly starting to see grey hairs here&there and I quite like it. I'm sure you'll get them as well, just hang in there!
:¬p
Sorry about that. If there ever were any "serious" ChucKists we probably scared them away by now.
I'm still not sure if there ever *is* a real need, sugar aside, to watch for two events or a event and a time. Still, I think it might be fairly easy; waiting for a event places that shred on the event's cue so waiting for multiple events would simply mean placing it on two cues and removing it from cue B once cue A fires. I'm not sure how that would have to interact with signal and broadcast though, The obvious way of doing it might lead to unexpected results because that would move everything below it in the "signal" cue one place up. The obvious solution would be recommending people don't combine "signal" with waiting for multiple events but I'm still not sure. _________________ Kassen |
|
Back to top
|
|
|
|