Re: [chuck-users] Object reference weirdness
![](https://secure.gravatar.com/avatar/616a90558aff47c06868ec154b8d70ec.jpg?s=120&d=mm&r=g)
In the meantime, what exactly is a bus error? What generally causes them? Bus errors can be caused by memory accesses that are misaligned: ie. a 32 bit read off of an odd memory address. Sounds like some pointer arithmetic going wrong somewhere in ChucK. -T
![](https://secure.gravatar.com/avatar/8a1ca9f288a1644e9e07d7f11d2f494c.jpg?s=120&d=mm&r=g)
Well, that might certainly explain my mysterious double-reference, no?
I will post a copy of the code on my site so that you can run it. It
probably won't be another few hours as I have class until 3pm on the
East Coast in the US. Also, being that this is part of a larger
project, I'm going to have to write out some instructions on running
it and point out how to recreate the strange behavior.
In the meantime, I should say that I've sort of given up trying to get
this to work for this project. I've come to the conclusion that Chuck
code that doesn't make any sound is a waste of time about 90% of the
time. The 10% that's left is generally very concise and elegant (my
code is neither concise nor elegant). Also, I think I'm coming to
understand that my dream of a class library for Chuck is somewhat
misguided. What I mean by that is my conception of a class library
comes from the Smalltalk-style library where everything builds on
everything else. This is great in purely object-oriented languages,
but not so much in Chuck.
I recently watched the Audicle demos again and have decided that Chuck
makes the most sense to me in the context of the Audicle. The Audicle
really plays to the strengths of Chuck, which are three things:
*Audio* and *Concurrency* in a *Networked* environment. The unit of
currency in Chuckland is not the object, it's the code file (or shred)
and thinking in this way makes way more sense. In the Audicle, it's
second nature, however, coming on the commandline it's a little
strange, since these things exist on your drive and not necessarily in
the VM.
Basically, I've decided I'm trying to get Chuck to do something that I
don't think Chuck is good at, which translates to bad design on my
part. I'm basically thinking inside the VM and I've got to start
thinking outside the VM. Chuck is a live-coding language in which you
deploy code and remove code from a running VM. But there's nothing to
say that the live-coder has to be a person: it could be another
program. My direction after I get the basic audio functions working
(which they mostly are now, thanks to Spencer and the rest of you ;-)
is to start writing programs to write Chuck code and deploy it on the
fly. Meta-live-coding, if you will. I'd rather build my arrays in
Python and have Python write them into my Chuck files. My "session"
would become the Chuck files that were generated while coding this
Python framework. Python will do the wheeling and dealing with the
Chuck VM and my Chuck code basically becomes a modular sound server.
This will be excellent on a network as well.
I might have just described my thesis right there... not sure.
Anyway, it also might be a complete failure.
I'll send my code out soon. I'm sure that I've just messed something
up in there somewhere and Chuck's bus error is really my fault.
-Mike
On Thu, Sep 25, 2008 at 3:34 AM, Tiemen Meerman
In the meantime, what exactly is a bus error? What generally causes them?
Bus errors can be caused by memory accesses that are misaligned: ie. a 32 bit read off of an odd memory address.
Sounds like some pointer arithmetic going wrong somewhere in ChucK.
-T
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
![](https://secure.gravatar.com/avatar/8a1ca9f288a1644e9e07d7f11d2f494c.jpg?s=120&d=mm&r=g)
Hi Chuckists,
As promised, my spaghetti code:
http://semiotech.org/code/Granular.zip
There's a README.txt file that has all the details about running the
code and where the issues are described. Thanks to anyone who takes
the time to look at this.
Cheers,
Mike
On Thu, Sep 25, 2008 at 9:32 AM, mike clemow
Well, that might certainly explain my mysterious double-reference, no?
I will post a copy of the code on my site so that you can run it. It probably won't be another few hours as I have class until 3pm on the East Coast in the US. Also, being that this is part of a larger project, I'm going to have to write out some instructions on running it and point out how to recreate the strange behavior.
In the meantime, I should say that I've sort of given up trying to get this to work for this project. I've come to the conclusion that Chuck code that doesn't make any sound is a waste of time about 90% of the time. The 10% that's left is generally very concise and elegant (my code is neither concise nor elegant). Also, I think I'm coming to understand that my dream of a class library for Chuck is somewhat misguided. What I mean by that is my conception of a class library comes from the Smalltalk-style library where everything builds on everything else. This is great in purely object-oriented languages, but not so much in Chuck.
I recently watched the Audicle demos again and have decided that Chuck makes the most sense to me in the context of the Audicle. The Audicle really plays to the strengths of Chuck, which are three things: *Audio* and *Concurrency* in a *Networked* environment. The unit of currency in Chuckland is not the object, it's the code file (or shred) and thinking in this way makes way more sense. In the Audicle, it's second nature, however, coming on the commandline it's a little strange, since these things exist on your drive and not necessarily in the VM.
Basically, I've decided I'm trying to get Chuck to do something that I don't think Chuck is good at, which translates to bad design on my part. I'm basically thinking inside the VM and I've got to start thinking outside the VM. Chuck is a live-coding language in which you deploy code and remove code from a running VM. But there's nothing to say that the live-coder has to be a person: it could be another program. My direction after I get the basic audio functions working (which they mostly are now, thanks to Spencer and the rest of you ;-) is to start writing programs to write Chuck code and deploy it on the fly. Meta-live-coding, if you will. I'd rather build my arrays in Python and have Python write them into my Chuck files. My "session" would become the Chuck files that were generated while coding this Python framework. Python will do the wheeling and dealing with the Chuck VM and my Chuck code basically becomes a modular sound server. This will be excellent on a network as well.
I might have just described my thesis right there... not sure. Anyway, it also might be a complete failure.
I'll send my code out soon. I'm sure that I've just messed something up in there somewhere and Chuck's bus error is really my fault.
-Mike
On Thu, Sep 25, 2008 at 3:34 AM, Tiemen Meerman
wrote: In the meantime, what exactly is a bus error? What generally causes them?
Bus errors can be caused by memory accesses that are misaligned: ie. a 32 bit read off of an odd memory address.
Sounds like some pointer arithmetic going wrong somewhere in ChucK.
-T
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
![](https://secure.gravatar.com/avatar/fa5a8de5c6e6c5838fc8106b390c7a6d.jpg?s=120&d=mm&r=g)
mike; What I mean by that is my conception of a class library
comes from the Smalltalk-style library where everything builds on everything else. This is great in purely object-oriented languages, but not so much in Chuck.
I see what you mean. Still; I feel that things like musicians, instruments, notes, phrases, modular-synth modules all have some "object" properties and it can make a lot of sense to think about them in that way. I also feel these concepts can have varying relations to each other, that it can make sense to group them, order them, sort them, etc, and that we may well like to do those kinds of things to those kinds of objects on the fly. To me this seems like a natural idea musically and on a structural level. Right now it's not all that clear how we should do some of this (some of it on the other hand is quite clear... other things are simply hard). I don't think this is a dead end. Right now your choice to focus on a different perspective is probably a good one but I very much like the idea of "everything building on everything" and we could use more of that. Not to "write Smalltalk in ChucK" as that makes little sense, but if we have a running "musician" object that's in some way connected to a "instrument" object I want to be able to take it's instrument away and hand it a new one, I want to be able to hand it a new phrase, to group several such "musicians" into a new "band" datatype... Currently I can do basically all of that using things like public classes with static members, having VM-wide events through which a "musician" controls his/her "instrument", that way I can have a lot of OTF control... as long as I know ahead of time what kind of control I will want in the future. If I have created this whole structure and ChucKed a band to a "stage" object and I decide I want musicians to be able to tickle each other I have a problem. Right now the more we create a framework for future freedom the more we define what kind of change is possible due to the nature of classes and public ones not being changeable. Smalltalk aside I think many of the underlying desires behind your attempts here can and do make musical sense; why shouldn't we have the ability to easily make a list that contains notes, phrases and instrument changes (maybe tickles as well)? Speaking purely for myself I feel that anything that makes musical sense should be expressible in ChucK, preferably in terms that aren't much more complicated then the intended effect.... Admittedly this is dreaming about a perfect future bound to arrive somewhere after flying cars, true artificial intelligence and Duke Nukem Forever but in the meantime I don't think we should content ourselves with describing ChucK's nature as not being capable of some of these structures, more like we haven't yet found a way to include that kind of functionality into the rest. Ok, that became quite general and philosophical but I felt compelled to reply to that side to your post. I'll have a more practical and focussed look at your code in the morning. Cheers, Kas.
![](https://secure.gravatar.com/avatar/3a90db9b434e5ba648e3e77afb4aff29.jpg?s=120&d=mm&r=g)
Bay Area Computer Music Technology Group (BArCMuT) Presentations and Telepresence Performance @ Mills College Thursday 10/2/08, 6:45pm Mills College, Music Building, Ensemble Room 5000 MacArthur Blvd., Oakland, CA 94613 Please RSVP Here: http://www.barcmut.org Thanks to Mills College for hosting the Bay Area computer music technology group this month! Presentation descriptions are below. Please come at 6:45 as the 30 minute tele-presence performance will begin at 7pm. 1) Telepresence event: Faculty and student performers at Mills will improvise with musicians in Chicago via an internet connection as part of the The Annual Chicago Calling Arts Festival. This will be a medium-fidelity connection (not Internet2), so the performers will be working within the inherent limitations of the ubiquitous medium artistically, rather than trying to demonstrate new technological abilities. For more information on the festival and this event visit http://www.chicagocalling.org . 2) Chris Brown talk about The Hub's network music composition "Vav" : Chris Brown will discuss and demonstrate the interactive systems used in "Vav", a network-music composition currently installed at the new Contemporary Jewish Museum in San Francisco as part of the John Zorn Presents the Aleph-Bet Sound Project. The piece was created by The Hub based on a protocol of data-exchange and musical responses among the six members of the group, each performing with their own computer instruments and software. An aesthetic that favors a balance between algorithimically generated and improvised musical actions in network music performance will be proposed. 3) Ge wang will present on Composing and Conducting for Laptop Orchestra: The presentation outlines some techniques for composing, performing, and conducting for laptop orchestra, drawing from experiences with the Stanford Laptop Orchestra (SLOrk) and Princeton Laptop Orchestra (PLOrk). In this context, we also look ahead to the upcoming Laptop Orchestra of the Left (LOL). The event will be in the ensemble room in the Mills College music building. Take the east-most entrance to Mills. The music building is the 3rd building on the right after entering campus and the ensemble room is on the ground floor at the far end of the building. Best, Noah Thorp Bay Area Computer Music Technology Group (BArCMuT) Organizer http://www.barcmut.org BIOS: CHRIS BROWN, composer, pianist, and electronic musician, creates music for acoustic instruments with interactive electronics, for computer networks, and for improvising ensembles. Collaboration and improvisation are consistent themes in his work, as well as the invention and performance of new electronic instruments. He is a member of the pioneering computer network band “The Hub” and is a Professor of Music and Co-Director of the Center for Contemporary Music (CCM) at Mills College in Oakland, California. www.cbmuse.com. Ge Wang ( http://ccrma.stanford.edu/~ge/ ) is currently an assistant professor at Stanford University in the Center for Computer Research in Music and Acoustics (CCRMA), having received his PhD in Computer Science in 2008 from Princeton University. His research interests include interactive software systems for computer music, programming languages, sound synthesis and analysis, music information retrieval, new performance ensembles (e.g., laptop orchestras) and paradigms (e.g., live coding), visualization, interfaces for human-computer interaction, and methodologies for education at the intersection of computer science and music. Ge is the chief architect of the ChucK audio programming language ( http://chuck.cs.princeton.edu/ ). He was a founding developer and co-director of the Princeton Laptop Orchestra (PLOrk), the founder and director of the Stanford Laptop Orchestra ( SLOrk - http://slork.stanford.edu/ ). He has co-founded the Mobile Phone Orchestra (MoPhO) and is establishing the Laptop Orchestra of the Left (LOL) in collaboration with the Bay Area Music Technology Group. Recently, Ge has co-founded SonicMule ( http:// www.smule.com ), a startup creating interactive sonic media. Ge composes and performs via various electro-acoustic and computer- mediated means.
participants (4)
-
Kassen
-
mike clemow
-
Noah Thorp
-
Tiemen Meerman