electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Articles  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links  |  Store
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » DIY Hardware and Software » ChucK programming language
a global LiSa
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [5 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Author Message
bigbadotis



Joined: May 17, 2009
Posts: 11
Location: santa barbara
Audio files: 1

PostPosted: Tue May 26, 2009 8:48 pm    Post subject: a global LiSa Reply with quote  Mark this post and the followings unread

I would like to be able to record a buffer into a LiSa object and then have different shreds that are live coded manipulate the voices in that buffer, change looping etc.

So far the only way I can figure out to do this is with static variables. Is the below code the shortest way to accomplish what I want?


Code:
adc => LiSa buff => dac;

public class loop {
    buff @=> static LiSa @ l;
}

loop loopy; // I have to instantiate this?

loop.l.duration(2::second);
loop.l.record(1);
2::second => now;
loop.l.record(0);

loop.l.play(1);

while(1) {
    2::second => now;
}


and then have another shred (from a different file) do something simple like:

Code:
loop.l.bi(1);


I feel like I'm often wanting to create instances of objects in one shred and then manipulate them in another. This seems to be counter to the ChucK way of doing things though... or am I just missing a key concept?

Thanks for any help. - Charlie
Back to top
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed May 27, 2009 5:16 am    Post subject: Reply with quote  Mark this post and the followings unread

Yes, I'd say this looks like a sensible way to go about this. I don't think there is a real need to keep the Shred that defines the LiSa alive as long as the LiSa is a static one.

Basically what we have here is a namespace issue; ChucK has a single UGen graph (that's a fancy name for the collection of UGens used and the way they are connected) for the whole VM, but code can only address UGens defined in it's scope, unless we pull trickery like this

As I see things this is completely according to "the spirit of ChucK", actually more so than our current set of limitations is. What we need is some way of navigating the namespace, for example by declaring things to be global in a more convenient way than encapsulating them in public classes. Because of the type-system that would run into issues if we'd also like to update those things. Fortunately the current situation does have a bit more space for trickery than you might think. Below I'm pasting a mail I send to the list early this year that demonstrates a sort of advanced version of what you are doing here as a proof of concept. I think you may find it interesting.

Quote:
Fellow ChucKists,

Inspired by Scott's explanation of casting I thought I'd try a new trick that may be quite interesting for livecoding.

first run this file;
-----------------------------
Code:
new UGen @=> Foo.instrument;
public class Foo
    {
    static UGen @instrument;
    spork ~attach();
   
    fun void attach()
        {
        while(1)
            {
            if(!instrument.isConnectedTo( dac )) instrument => dac;
            second => now;
            }
        }
    }

Foo foo;
new Sitar @=> foo.instrument;

//your melody goes here
while(second => now) 1 => (foo.instrument $ Sitar).noteOn;
--------------------------------------------

Then run this to hot-swap the UGen while the original code runs;

--------------
Code:
new Shakers @=> Foo.instrument;

-----------------------

Sadly this does need that "attach" function as assignment breaks the link to the dac. I'm not sure I feel that's desirable behaviour but at least we can now hotswap UGens without crashing. I don't think I succeeded in that before.

Yours,
Kas.


Some people have pleaded for "duck typing" in ChucK and I think that this demonstrates that if you are willing to "cast up&down" you can have that. Of course this is playing with fire as we are bypassing the parser's ability to type-check so a mistake there will crash.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Wed May 27, 2009 5:17 am    Post subject: Reply with quote  Mark this post and the followings unread

Also; "welcome on board" :¬)
_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
bigbadotis



Joined: May 17, 2009
Posts: 11
Location: santa barbara
Audio files: 1

PostPosted: Wed May 27, 2009 3:53 pm    Post subject: Reply with quote  Mark this post and the followings unread

Thanks for the help and for looking at my code... even just getting rid of the time loop will save me a few seconds typing at the gig, nice.

And yes, a simple way to make things global would be great... glad to hear it's just a current limitation and not a design decision.

Looking at your code was also helpful, thanks again. - Charlie
Back to top
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Thu May 28, 2009 2:59 am    Post subject: Reply with quote  Mark this post and the followings unread

Yes, basically you can say that when the scope a UGen was defined in seizes to exist it will be removed from the UGen graph. With static members of public classes that scope is VM-wide so it will never be removed, hence there is no need for the infinite loop. There are some odd exceptions to that but as a rule of thumb it works.

About the design choices; bear in mind that this is just my opinion. It's a informed opinion but no guarantee that Ge will see it the same way. I also don't think it's clear exactly what needs to be done to make ChucK more friendly to livecoding while preserving the bits that makes sense now; there have been some design suggestions for that but nothing concrete that I know of.

Good luck with your gig. Do share interesting techniques that you find and if there would be recordings I'd be quite interested.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Kassen
Page 1 of 1 [5 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
 Forum index » DIY Hardware and Software » ChucK programming language
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
e-m mkii

Please support our site. If you click through and buy from
our affiliate partners, we earn a small commission.


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use