[CM] some CM sprout/process questions
Larry Troxler
lt@westnet.com
Sat, 28 Sep 2002 19:39:44 -0400 (EDT)
Thanks again, Micheal.
I don't really know the difference between make-instance and
allocate-instance, except that make-instance is a CLOS function, and
that I couldn't find allocate-instance in either the Common Lisp or the
Common Music documentation I have.
My first impulse was, not knowing any better, to redefine copy-object as
you have suggested. So I'll try that. Weird, however, that it's not
working as is.
Regarding your suggestion of calling the "events" function with a list of
timed events, I am not sure that this really fits my needs unless this
list of events could somehow be sprouted.
I think I will take some time to look through the CM source code and
experiment a bit. I do get the feeling that there are some things that are
undocumented in CM, but yet probably work just fine.
Larry Troxler
On Sat, 28 Sep 2002, Michael Klingbeil wrote:
> Interesting error. I don't have access to CMUCL on Linux, so I can't
> really test this. I think this is an issue Rick Taube or others could
> look into.
>
> For the moment you could just redefine copy-object, replacing
> allocate-instance with make-instance. I think the idea was that by
> calling allocate-instance, object initialization is bypassed (thus
> avoiding any possible side-effects), thus allowing the source object
> to be directly "cloned."
>
> But for the purposes of CM, this should be fine:
>
> (defmethod copy-object ((object standard-object))
> (let* ((class (class-of object))
> (new (make-instance class)))
> (fill-object new object)
> new))
>
>
> The other way is to just initialize all slots in the new maco
>
> (setf foo (new i ins 1 time 1.45 duration 4.2))
>
> I hope these suggestions are helpful.
>
>
> >Greetings, Micheal. It seem that it's allocate-instance that's somehow
> >undefined. The following is with CM 2.3.4, on Linux Cmucl:
> >
> >
> >* (setf foo (new i))
> >
> >#e(i)
> >* (setf bar (copy-object foo))
> >
> >
> >No matching method for the generic-function #<Standard-Generic-Function
> >ALLOCATE-INSTANCE (3)
> > {281B4229}>,
> >when called with arguments (#<STANDARD-CLASS I {282AB2AD}>).
> >
> >On Fri, 27 Sep
> >2002, Michael Klingbeil
> >wrote:
> >
> >> It sounds like each time you are calling 'sv' on your object 'o', you
> >> are overwriting the old slot values. This is one of those examples
> >> where the functional programmers will shout "side effects are bad!"
> >> This isn't a problem if you are immediately sending events out the
> >> midi-port, but if you are putting them into a seq or something like
> >> that, then you need a new object for each event.
> >>
> >> Your idea of using copy-object is definitely on the right track and
> >> in fact it should work. Copy-object should work for any kind of CLOS
> >> object... I have used it for stuff not even CM related. What kind of
> >> error are you getting when you attempt to use copy-object? What
> >> version of CM do you have? Maybe there is an old bug?
> >>
> >> What I often do to avoid any of this is something like
> >>
> >> (output (new csound-event-subclass ...))
> >>
> >> just setting the slot values in each output statement. If this is
> >> tedious, then copy-object should (ideally!) do the trick.
> >>
> >> You can avoid using defprocess entirely and just insert events into a list:
> >>
> >> (setf my-events
> >> (list (new csound-event-subclass ...)
> >> (new csound-event-subclass ...)
> >> (new csound-event-subclass ...)
> >> ...))
> >>
> >> (events my-events "mypiece.sco" 0 ...)
> >>
> >>
> >>
> >>
> >>
> >> >My goal is that I would to sprout a short (say three or four) sequence
> >> >of csound score events.
> >> >
> >> >I thought that rather than hassle with patterns, it would be simpler and
> >> >easier to read, if I can simply write a handfull of sv's and output's
> >> >linearly, so to speak.
> >> >
> >> >For example,
> >> >
> >> >(defprocess note ()
> >> > (let (o (new csound-event-subclass ...))
> >> > process repeat 1 do
> >> > (sv o ...)
> >> > (output o)
> >> > (sv o ...)
> >> > (output o)
> >> > (sv o ....)
> >> > (output o)
> >> > wait 4))))
> >> >
> >> >With this process I intend to define a conceptual "note" that is a short
> >> >sequence of csound events (in this particular case, using a negative p3
> >> >on all but the last event).
> >> >
> >> >In this situation, I want to create an object "o" in the let
> >> >initialization and define the values of most of the slots. In the "sv"'s
> >> >I will modify only one or two of the slots.
> >> >
> >> >I tried the above method both by setting the time slot in the "sv"
> >> >functions, and by providing the optional start-time parameter to the
> >> >"output" functions.
> >> >
> >> >The problem is that it seems that the "sv" calls happen all at once, so
> >> >what happens is that the second and third outputs both get the final
> >> >(third) values of the slots.
> >> >
> >> >I then tried using "copy-object" to use a seperate clone an instance of
> >> >the prototype csound object before modifying it for each output, but for
> > > >some reason the "copy-object" method ends up being undefined for my
> >> >csound event subclass.
> >> >
> >> >Questions:
> >> >
> >> >1. Is there a better idiom for this type of thing? In particular, it
> >> >seems awkward to have to define a process using "repeat 1" for this.
> >> >
> >> >2. What doesn't the default copy-object method work? Do I really need to
> >> >define one for every csound subclass? I would think that copy-object by
> >> >default would simply copy all the slots, but is this not the case?
> >> >
> >> >
> >> >Regards
> >> >
> >> >Larry
> >> >_______________________________________________
> >> >Cmdist mailing list
> >> >Cmdist@ccrma.stanford.edu
> >> >http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
> >>
> >> _______________________________________________
> >> Cmdist mailing list
> >> Cmdist@ccrma.stanford.edu
> >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
> >>
> >
> >-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --
>
> _______________________________________________
> Cmdist mailing list
> Cmdist@ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
>
-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --