On Wed, 2004-01-14 at 20:31, Larry Troxler wrote:
Ok, and I know this is probably an ignorant question, but could you possibly be a bit more specific? (Sorry I lost your original reply). I know you said it's just a matter of loading it and then running (cm), but where did you do this?
Yeah, I know that it was very naive but I loaded the CM system within the same script I loaded into k_guile. I think this is why Kjetil wrote back saying that you can have CM load by default by editing the global.scm file, and then later proposed loading a conf file (I still haven't had time to check out the improvements from CVS). Here's my naive script:
(pd-inlets 1) (pd-outlets 1)
(load "/home/mis/CommonL/cm/src/cm.scm") (cm)
(pd-inlet 0 'float (lambda (x) (pd-outlet 0 (hertz x))))
call it float->hertz if you wish :)
(side note: this presents me with a little problem: CM's hertz function will take a float/int argument as well as string (a note name with octave indication like c4) and a list (of ints/floats or strings). It seems that I have to specify type for the inlet so I cannot feed the same inlet with different types? Also, I seem not to know how to handle list types with k_guile or there's a bug... But I had not enough time to play with this.)
Does CM really keep it's state between k_quille objects?
I guess not if CM is loaded the way I did above. Perhaps it does if you load it globally?
I.e. can you make an object that reads items from a stream, and then create other objects that read items from the same stream? What happens if you close all your objects, and then re-open them again? is the state of Common Music still preserved?
... good questions...
Sorry for sounding so confused, but I am :-) I had always thought that the only way to make this kind of persistence work would be to load the thing as a library, once, and once only. It's kind of confusing me to think of how this concept works in the case of a load-on-demand library in linux...
I guess you're right. I don't think that loading CM with every instance of your k_guile is the right thing to do. I haven't have the time to explore any further since the last time I tried it. I also don't have enough knowledge (about lisp/scheme/CM/pd externs programming) to contribute anything meaningful, but I like the idea of having CM in pd and I'm willing to test and try and err. Recently I have motivated myself to dive into CM and so this extern came at a right time :) But I'm still fighting my way through Touretzky ...
I still have the feeling that I'm missing a very basic point here, or else I am completely misunderstanding what Kjetil is telling me...
I tried to follow more or less your discussion with Kjetil and I sort of can see what you're getting at. Seems to me, also, that Kjetil didn't intend for this extern to become a robust environment for running CM :) It definitely works as a simple scheme interpreter (but I still have issues with lists...). I'm not yet sure if I'd actually use all the power of CM, I was thinking more about simply using some of the functions (or building some around those of CM) for use within the PD usual spaghetti.
Otherwise, your ideas about persistence and stuff like that sound a little like elvish to me but I hope to catch up in time...
./MiS