On Mon, 2004-01-05 at 06:15, Kjetil Svalastog Matheussen wrote:
k_guile is a guile PD external.
wow. cool. Common Music within pd is now possible...
On Monday 05 January 2004 12:10, Michal Seta wrote:
On Mon, 2004-01-05 at 06:15, Kjetil Svalastog Matheussen wrote:
k_guile is a guile PD external.
wow. cool. Common Music within pd is now possible...
Yes, very nice. I think this officially obsoletes my pd_scheme library. (It was built on Scheme In One Day, which isn't a full-featured standard Scheme).
Kjetil, I see you took a different approach than I did, one that is a bit simpler. In my case a single interpreter is loaded as a library, which loads scheme source code that defines various PD objects that can be instantiated. These objects can then communicate with eachother using scheme.
Your approach definitely has the advantage of simplicity though, and in practice it may not be any less powerfull.
For running something like Common Music (Michal, have you tried it yet?) it
would probably be nice to be able to run scheme in a seperate thread, so that
long computations and garbage collection don't cause dropouts. But I think
that running this external in a second PD connected to the primary one with
netsend and netreceive should work, right?
In any case, I'm looking forward to trying this external. Thanks!
Larry Troxler
On Sat, 2004-01-10 at 11:34, Larry Troxler wrote:
Yes, very nice. I think this officially obsoletes my pd_scheme library. (It was built on Scheme In One Day, which isn't a full-featured standard Scheme).
Since I think (or did I dream that up?) you said that you would port it possibly to guile I was silently waiting for that to happen... :)
Kjetil, I see you took a different approach than I did,
What I liked in Larry's extern was that I could send arbitrary scheme expressions to it... But I don't know if this is a real advantage, certainly helps trying out things...
For running something like Common Music (Michal, have you tried it yet?)
I didn't really have time to play with it so much. Not to mention that I'm only slowly learning scheme/lisp/CM. I did manage to load CM and call some functions but I haven't actually done anything useful yet.
One thing I noticed, though, is that when you load the whole CM system into a script and then make changes in the script and reload (even completely destroying the object and creating a new one) it in pd, pd segfaults reliably (would there be a way to load CM once and then access it from other .scm scripts?). Otherwise, running simple scripts, changing them and reloading works fine.
./MiS
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
On Sat, 2004-01-10 at 11:34, Larry Troxler wrote:
Yes, very nice. I think this officially obsoletes my pd_scheme library. (It was built on Scheme In One Day, which isn't a full-featured standard Scheme).
Since I think (or did I dream that up?) you said that you would port it possibly to guile I was silently waiting for that to happen... :)
Kjetil, I see you took a different approach than I did,
What I liked in Larry's extern was that I could send arbitrary scheme expressions to it... But I don't know if this is a real advantage, certainly helps trying out things...
For running something like Common Music (Michal, have you tried it yet?)
I didn't really have time to play with it so much. Not to mention that I'm only slowly learning scheme/lisp/CM. I did manage to load CM and call some functions but I haven't actually done anything useful yet.
One thing I noticed, though, is that when you load the whole CM system into a script and then make changes in the script and reload (even completely destroying the object and creating a new one) it in pd, pd segfaults reliably (would there be a way to load CM once and then access it from other .scm scripts?). Otherwise, running simple scripts, changing them and reloading works fine.
./MiS
_
__ __ (_)___ Michal Seta
/ \/ \ _/^ _|
/ V |_ \ @creazone.32k.org
(___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
On Saturday 10 January 2004 17:05, Michal Seta wrote:
On Sat, 2004-01-10 at 11:34, Larry Troxler wrote:
Yes, very nice. I think this officially obsoletes my pd_scheme library. (It was built on Scheme In One Day, which isn't a full-featured standard Scheme).
Since I think (or did I dream that up?) you said that you would port it possibly to guile I was silently waiting for that to happen... :)
Well, I'm sorry if you were holding your breath! II'd love to do a lot of things but my free time is limited. I'm glad it happened though. Sorry if I promised something that I didn't deliver (but I don't think I ever said that I was definitely going to do it, only that it would be nice (?)) Grr. Maybe I had an optimisitic moment at one point and said I would port it that weekend, or something like that <sigh>.
Kjetil, I see you took a different approach than I did,
What I liked in Larry's extern was that I could send arbitrary scheme expressions to it... But I don't know if this is a real advantage, certainly helps trying out things...
For running something like Common Music (Michal, have you tried it yet?)
I didn't really have time to play with it so much. Not to mention that I'm only slowly learning scheme/lisp/CM. I did manage to load CM and call some functions but I haven't actually done anything useful yet.
Well that's a good start! Was it straightforward? I'm probably going to try this tonight. It truly would be great to have a robust CM running inside PD.
The missing element I think is that to take full advantage of Common Music (or any Lisp environment for that matter) in a PD environment, you would want an interactive listener into the interpreter that is running inside PD. In other words, in an ideal world, I'd like to be able to load up scheme inside PD, and then from Emacs or whatever, be able to evaluate expressions inside that interpreter, while PD is running (I imagine through an IP socket).
One thing I noticed, though, is that when you load the whole CM system into a script and then make changes in the script and reload (even completely destroying the object and creating a new one) it in pd, pd segfaults reliably (would there be a way to load CM once and then access it from other .scm scripts?).
Hmm, right now I didn't even know that it's possible to reload a script in to a running PD object (did you set the script up to reload your source file upon receiving a PD message?). I should probably shut up now unti I actually try this external myself.
Larry
On Sat, 2004-01-10 at 17:51, Larry Troxler wrote:
Well, I'm sorry if you were holding your breath!
I wasn't really...
(but I don't think I ever said that I was definitely going to do it, only that it would be nice (?))
Yeah, I think that was more like it.
Well that's a good start! Was it straightforward?
Yup.
(load "/path/to/cm/src/cm.scm") (cm) ; and it prints the cute ascii cm logo in the shell :)
I'd like to be able to load up scheme inside PD, and then from Emacs or whatever, be able to evaluate expressions inside that interpreter, while PD is running (I imagine through an IP socket).
hmm... yeah... That'd be nice. I can't do this but if [k_guile] were able to evaluate scheme expressions sent through an inlet it would already be easy to hack something up.
Hmm, right now I didn't even know that it's possible to reload a script in to a running PD object
k_guile extern accepts 'reload' message.
cheers,
./MiS
(Including our beloved author Kjetil on this message ...)
On Saturday 10 January 2004 20:34, Michal Seta wrote:
On Sat, 2004-01-10 at 17:51, Larry Troxler wrote:
Well, I'm sorry if you were holding your breath!
I wasn't really...
That's good, because otherwise you would be dead by now, and your survivors would be suing me.
Well that's a good start! Was it straightforward?
Yup.
(load "/path/to/cm/src/cm.scm") (cm) ; and it prints the cute ascii cm logo in the shell :)
Cool! How often do things work out that simply? Of course my Common Music experimenting has been Common Lisp and not Scheme, so first, I'll have to install the guille version, and second, I'll have to forget about being able to take advantage of all the nice high level CM functions :-(
But having a PD object that reads out items from nested Common Music patterns (that you can edit sanely in a lisp environment), will be quite a bit nicer than trying to do the same thing with qlist text files, don't you think?
Kjetil, speaking of paths, it would be better IMO if you use the PD search path to load your scheme files, instead of only looking in the current directory. What I did in my pd_scheme external was to define a C callback in scheme, which callled the PD path search routine.
I think this bit is very much needed for practical use, unless people want to copy all the scheme files they use into the directory that they run PD from.
For example, your help file doesn't run as is, with your current approach.
Understand, please, that this is a minor point overall, and I thank you for providing this way cool tool for us PD users!
Another minor point, it would be nice if PD timers (or maybe "clocks" is the PD nomenclature, I don't remember) were supported as well.
But really, actually, either of the above two points I could tackle myself. Just let me know (a) if you want me to, and (b) if you're willing to handle an open-ended time frame for which these things will be implemented (although they both are quite simple).
I'd like to be able to load up scheme inside PD, and then from Emacs or whatever, be able to evaluate expressions inside that interpreter, while PD is running (I imagine through an IP socket).
hmm... yeah... That'd be nice. I can't do this but if [k_guile] were able to evaluate scheme expressions sent through an inlet it would already be easy to hack something up.
Would it really be that easy? How would you go about hooking up an Emacs listener, for example, using this approach? It would have to go through a socket and all that stuff, no? I mean, it _is_ saturday night here so I don't feel like dwelling on the details, but if you think you have an easy way to make something work, let us know!. Sure, it would be easy to type an sexpr into a PD message dialog and see the result, and granted, that would be far better than nothing, but it certainly wouldn't take the place of being able to use a nice lisp-aware editor to interact.
Hmm, right now I didn't even know that it's possible to reload a script in to a running PD object
k_guile extern accepts 'reload' message.
Yeah, I see that now that I have it running.
Going to try to install guile CM now ...
fun, fun, fun :_)))
Larry
On Sat, 2004-01-10 at 21:47, Larry Troxler wrote:
hmm... yeah... That'd be nice. I can't do this but if [k_guile] were able to evaluate scheme expressions sent through an inlet it would already be easy to hack something up.
Would it really be that easy?
well, not really, but something.
How would you go about hooking up an Emacs listener, for example, using this approach? It would have to go through a socket and all that stuff, no?
yeah. It would take a module/mode in emacs that'd be able to send expressions via socket (in fact, I _think_ that this is how the emacs frontend to SuperCollider works but haven't really looked). Or, it might be useful to set up the k_guile process in such a way that one can get into it from emacs. Or even pd? Am I talking nonsense? Well, it works for ecasound :)
-- ./MiS
On Sunday 11 January 2004 02:43, Michal Seta wrote:
On Sat, 2004-01-10 at 21:47, Larry Troxler wrote:
How would you go about hooking up an Emacs listener, for example, using this approach? It would have to go through a socket and all that stuff, no?
yeah. It would take a module/mode in emacs that'd be able to send expressions via socket (in fact, I _think_ that this is how the emacs frontend to SuperCollider works but haven't really looked). Or, it might be useful to set up the k_guile process in such a way that one can get into it from emacs. Or even pd? Am I talking nonsense? Well, it works for ecasound :)
No, I think this is the right approach, I'm just not sure how easy it is to do in Guile. I know some Common Lisps support multithreading and have an IP socket API. For all I know, Guile might have the same ability, I just haven't used it in depth before so I don't know.
Larry
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
Cool! How often do things work out that simply? Of course my Common Music experimenting has been Common Lisp and not Scheme, so first, I'll have to install the guille version, and second, I'll have to forget about being able to take advantage of all the nice high level CM functions :-(
But having a PD object that reads out items from nested Common Music patterns (that you can edit sanely in a lisp environment), will be quite a bit nicer than trying to do the same thing with qlist text files, don't you think?
Going to try to install guile CM now ...
Could anyone give some quick pointers on how to install Common Music for guile (or at all) on Linux? Besides reading the SICP book I'm an Lisp idiot and I even use Vim, not Emacs, so any pointers would be welcome...
ciao
Frank Barknecht _ ______footils.org__
Severe case of Insomnia here - good morning Europe. Wait no, actually it's almost time for lunch for you guys. I don't know what brought this on, but I suspect the peperoni and anchovy pizza I had last night. grrrr. Now it will be getting light out soon. I guess my Sunday isn't going to be very productive, huh?
On Sunday 11 January 2004 05:02, Frank Barknecht wrote:
Could anyone give some quick pointers on how to install Common Music for guile (or at all) on Linux? Besides reading the SICP book I'm an Lisp idiot and I even use Vim, not Emacs, so any pointers would be welcome...
ciao
I still haven't installed the scheme version of Common Music, but have played extensively with the Common Lisp version over the years, and have come to regard the Common Lisp language quite highly, especially for an interactive situation like music. In effect, Lisp lets you define your own language for the situation at hand. In that respect I suppose it's more similar to languages like Forth, than it is to C/C++. I think it has greatly suffered from misconceptions, like it's interpreted and therefore slow (not true - lisp is incremementally compiled these days) and the like. The other big problem is that CL doesn't have a lot of standard libraries to do GUI stuff and the like. It's a shame, because I think the language itself is fantastic, and apparently I'm not the only one, because a lot of bright minds seem to be drawn to Lisp.
Unfortunately, Scheme isn't quite the be-all-and-end-all of languages that Common Lisp is, but I have to have faith :-) But I think I need to try to sleep for a while before installing it.
Did you have specific questions about CM? I would think that there would be a lot of help on CCRMA - Rick Taube seems usually to be pretty good about installation instructions.
Do take the time to play with Lisp. As a long time C/C++ programmer, it really opened my mind a bit. Again, unfortunately, with PD you will have to run CM in scheme, which is more of a minimalist, academic language, rather than in Common Lisp, which to me is much more practical and powerfull.
Well, I'm gonna try to sleep before the sun comes up. I'll probably have more to say later today once I install guile CM and load it into PD.
Larry
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
Did you have specific questions about CM? I would think that there would be a lot of help on CCRMA - Rick Taube seems usually to be pretty good about installation instructions.
I also did a bit of googling and as I'm Debian centric, I found this recent Agnula mailing: http://lists.agnula.org/pipermail/developers/2004-January/003504.html which states that CM is being packaged on Agnula for Guile and CMU CLisp currently (but probably not done yet).
Anyway as I'm not in a real hurry to install CM I will just wait for the Agnula package to get ready ;)
Good night ;)
ciao
Frank Barknecht _ ______footils.org__
On Sunday 11 January 2004 06:04, Frank Barknecht wrote:
Hallo,
Larry Troxler hat gesagt: // Larry Troxler wrote:
Did you have specific questions about CM? I would think that there would be a lot of help on CCRMA - Rick Taube seems usually to be pretty good about installation instructions.
I also did a bit of googling and as I'm Debian centric, I found this recent Agnula mailing: http://lists.agnula.org/pipermail/developers/2004-January/003504.html which states that CM is being packaged on Agnula for Guile and CMU CLisp currently (but probably not done yet).
Anyway as I'm not in a real hurry to install CM I will just wait for the Agnula package to get ready ;)
Ok, whatever. Seems very bizarre to me, but to each his own, I guess. I suppose I don't see what the problem is that's supposedly solved by packaging it up into an "Agnula package". To me, that just adds an additional layer of possible complication.
Good night ;)
ciao
Yeah, ok, turning the computer off for real now. I think it's not the pizza but the espresso shot I made that's keeping me up.
Larry
On Sun, 2004-01-11 at 05:02, Frank Barknecht wrote:
Could anyone give some quick pointers on how to install Common Music for guile (or at all) on Linux? Besides reading the SICP book I'm an Lisp idiot and I even use Vim, not Emacs, so any pointers would be welcome...
go to http://commonmusic.sf.net, download and unpack the common music package.
Assuming you already have Guile installed (I think CM works only with guile ATM) start it ('guile')
in the guile interpreter type:
(load "/path/to/cm/src/cm.scm") (cm)
and you're inside CM. You can now start fiddling around. H.Taube's book used to be up on the web somewhere but he took it down because i's going to print...
There are some examples in the cm/etc directory and a reference manual in the doc directory.
have fun.
BTW, what's SICP book?
-- ./MiS Michal Seta mis@creazone.32k.org
Frank Barknecht wrote:
Could anyone give some quick pointers on how to install Common Music for guile (or at all) on Linux? Besides reading the SICP book I'm an Lisp idiot and I even use Vim, not Emacs, so any pointers would be welcome...
You can work with CM from vi just as easily as from emacs. Emacs has the particular amenity of being able to evaluate your Lisp expressions from within itself. You can do something similar with vi's shell command but I'll recommend at least learning how to use xemacs. I did a lot of work with Lisp in vi before I learned a little more about emacs. I still prefer vi for writing but I like using emacs for Common Music.
And Frank: Lisp is 'way cool, very easy to learn, you'll get used to it quickly. You don't need to learn everything about the language to use the Common apps, and if you have any background in another language you'll find Lisp very straightforward to acquire.
Have fun !
PS: I'm interested to see what possibilities evolve from this Pd + CM liaison...
Best,
== dp
Hallo, Dave Phillips hat gesagt: // Dave Phillips wrote:
And Frank: Lisp is 'way cool, very easy to learn, you'll get used to it quickly. You don't need to learn everything about the language to use the Common apps, and if you have any background in another language you'll find Lisp very straightforward to acquire.
Well, I do know Lisp a littly bit. Re: Micheal: The SCIP book, which I read (first half only yet) is a seminal book in computer science fully pronounced: "Structure and Interpretation of Computer Programs". Full text is online here: http://mitpress.mit.edu/sicp/ It uses Scheme as example language.
But as with Go or Chess: knowing the rules, which are very simple in Lisp, is one thing, and in the case of Go, Chess and Lisp it seems to be the most tiny thing in mastering the game. As I never really *used* Lisp, be it in music or in Emacs, I termed myself a "Lisp idiot". ;)
ciao
Frank Barknecht _ ______footils.org__
On Sunday 11 January 2004 17:29, Frank Barknecht wrote:
Hallo,
Dave Phillips hat gesagt: // Dave Phillips wrote:
And Frank: Lisp is 'way cool, very easy to learn, you'll get used to it quickly. You don't need to learn everything about the language to use the Common apps, and if you have any background in another language you'll find Lisp very straightforward to acquire.
Well, I do know Lisp a littly bit. Re: Micheal: The SCIP book, which I read (first half only yet) is a seminal book in computer science fully pronounced: "Structure and Interpretation of Computer Programs". Full text is online here: http://mitpress.mit.edu/sicp/ It uses Scheme as example language.
Ahh, so you know Scheme, not Common Lisp. Although based on the same syntax and principles, they are quite different languages, with almost opposite goals. Scheme is a small, elegant teaching language, whereas Common Lisp is a very high level, full-featured, get-the-job-done-fast practical language.
So don't write off the Lisp family of languages altogether until you've tried, say, Common Music running in Common Lisp.
In fact, at my day job, for the kind of jobs that most people would probably use either a spreadsheat app, or Mathcad for, I tend to use CLISP (well hey, it's a Windows machine)
It's fast, it's powerfull, and it's interactive.
But as with Go or Chess: knowing the rules, which are very simple in Lisp, is one thing, and in the case of Go, Chess and Lisp it seems to be the most tiny thing in mastering the game. As I never really *used* Lisp, be it in music or in Emacs, I termed myself a "Lisp idiot". ;)
ciao
Don't worry about mastering it, and don't worry about comparing it to the programming languages that you already know. Just spend some time playing with Common Music (IMHO). Best to treat it as a game, play time, if you know what I mean. (Like what we do when we make music!). Try typing expressions into the interpreter, and see what comes out. Experiment.
Or maybe you've already gone down this route and were dissapointed. If so, then hey, everone's different.
If you're coming from a C/C++/Pascal/Basic background, as was the case with me, then yes, this strange syntax seems very foreign at first. But once you spend a week or two of your free time with it, you may start to get the "a-ha" reaction.
Or maybe not ;-)
Larry
Hallo, (now it's me not getting to bed ... ;)
Larry Troxler hat gesagt: // Larry Troxler wrote:
On Sunday 11 January 2004 17:29, Frank Barknecht wrote:
Well, I do know Lisp a littly bit. Re: Micheal: The SCIP book, which I read (first half only yet) is a seminal book in computer science fully pronounced: "Structure and Interpretation of Computer Programs". Full text is online here: http://mitpress.mit.edu/sicp/ It uses Scheme as example language.
Ahh, so you know Scheme, not Common Lisp. Although based on the same syntax and principles, they are quite different languages, with almost opposite goals. Scheme is a small, elegant teaching language, whereas Common Lisp is a very high level, full-featured, get-the-job-done-fast practical language.
So don't write off the Lisp family of languages altogether until you've tried, say, Common Music running in Common Lisp.
Just to make sure I haven't been misunderstood: I *am* very interested in Lisp/Scheme, that's one reason I read the SCIP. And having learned the basics and some in Perl (rest in peace), Python and C++ I guess Lisp is something that would be natural to get to know next. Making and understanding music always was one of my motivations for learning to program. I won't write Lisp off.
Although I'm a bit surprised that I got so much encouragment here on a Pd list! ;)
Anyways: as Lisp is soo old, it's sometimes difficult not to be intimidated by achievments like Snd or Emacs, which are like mountains one seems to need special gear for (the SCIP book is a mountain in this regard, too). But then, Pd's not exactly lowlands as well.
So I'm glad for your and the others' hands-on tips. Thanks a lot.
ciao
Frank Barknecht _ ______footils.org__
ok, I know this getting further and further off topic...
On Sun, 2004-01-11 at 17:29, Frank Barknecht wrote:
Well, I do know Lisp a littly bit. Re: Micheal: The SCIP book, [...] http://mitpress.mit.edu/sicp/ It uses Scheme as example language.
thanks. Just in case you haven't come across these (you prolly did...): http://www-2.cs.cmu.edu/~dst/LispBook/index.html & http://www.paulgraham.com/onlisptext.html
-- ./MiS Michal Seta mis@creazone.32k.org
On Sunday 11 January 2004 11:26, Dave Phillips wrote:
PS: I'm interested to see what possibilities evolve from this Pd + CM liaison...
Well, for one thing, this could be a _very_ roundabout way of getting real-time MIDI output working from Common Music on Linux :-))
My apologies if it already does in the recent distros of CM, but the last I checked, Rick and company were still looking for someone to get the MIDI playback working in Linux.
(Of course we would like a timer object in k_guille for this. Wait, did I actually volunteer to do this? Grrr. )
Larry
Hi
trying the binary with OS X i am having problems selecting the jack audio server
Could not create format converter: error = 0x666D743F = 'fmt?' PaOSX_OpenCommonDevice: PAOSX_DevicePropertyListener failed. : error = 0x666D743F = 'fmt?' Error number -10000 occured opening portaudio stream Error message: Host error
Patrick Pagano,B.S. M.F.A candidate http://www.digitalworlds.ufl.edu http://www.screwmusicforever.com/SHREESWIFT
On Sunday 11 January 2004 10:48, Michal Seta wrote:
On Sun, 2004-01-11 at 05:02, Frank Barknecht wrote:
Could anyone give some quick pointers on how to install Common Music for guile (or at all) on Linux? Besides reading the SICP book I'm an Lisp idiot and I even use Vim, not Emacs, so any pointers would be welcome...
go to http://commonmusic.sf.net, download and unpack the common music package.
Assuming you already have Guile installed (I think CM works only with guile ATM)
Uh well no, of course it also works with a lot of Common LIsp's.
On Sun, 2004-01-11 at 14:46, Larry Troxler wrote:
Assuming you already have Guile installed (I think CM works only with guile ATM)
Uh well no, of course it also works with a lot of Common LIsp's.
Yes it does! What I meant to say is that the scheme implementation works only with guile. Sorry for misleading.
On Sat, 10 Jan 2004, Larry Troxler wrote:
On Monday 05 January 2004 12:10, Michal Seta wrote:
On Mon, 2004-01-05 at 06:15, Kjetil Svalastog Matheussen wrote:
k_guile is a guile PD external.
wow. cool. Common Music within pd is now possible...
Yes, very nice. I think this officially obsoletes my pd_scheme library. (It was built on Scheme In One Day, which isn't a full-featured standard Scheme).
Kjetil, I see you took a different approach than I did, one that is a bit simpler. In my case a single interpreter is loaded as a library, which loads scheme source code that defines various PD objects that can be instantiated. These objects can then communicate with eachother using scheme.
Yes, I looked at your external. And I think your solution is prettier in a way, but also harder to understand, and not very much more powerful, so I did it "my way". ;)
Your approach definitely has the advantage of simplicity though, and in practice it may not be any less powerfull.
For running something like Common Music (Michal, have you tried it yet?) it would probably be nice to be able to run scheme in a seperate thread, so that long computations and garbage collection don't cause dropouts.
When using realtime priority on the audio thread, any non-realtime thread shouldn't cause a dropout... At least in linux. Perhaps it can in macosX? So I'm not too eager to add threads-support. However, guile does support threads (documented in the manual), so perhaps the pd-* functions should be made thread-safe? If there is a demand, it shouldn't be to hard to do.
But I think that running this external in a second PD connected to the primary one with netsend and netreceive should work, right?
Should work.
On Sunday 11 January 2004 10:56, Kjetil Svalastog Matheussen wrote:
When using realtime priority on the audio thread, any non-realtime thread shouldn't cause a dropout... At least in linux. Perhaps it can in macosX?
But it doesn't look like you're using a seperate thread at all (?) I'm using pd-0.36-devel still, so maybe things are different now, but if so that would have been quite a radical reworking of PD, to have the message processing be in a seperate thread than the audio.
So I'm not too eager to add threads-support. However, guile does support threads (documented in the manual), so perhaps the pd-* functions should be made thread-safe? If there is a demand, it shouldn't be to hard to do.
Again, I'm a bit confused. I had always thought, that unless you launch a thread on your own, that PD was single-threaded, and that it relied on message processing to be fast enough to not cause audio dropouts - hence there seems to be no reason at the moment to make your functions thread-safe. Now of course, it would be nice if your external worked off-line in an other thread, in which case re-entrancy might be then a factor.
But I think that running this external in a second PD connected to the primary one with netsend and netreceive should work, right?
Should work.
Larry
On Sun, 11 Jan 2004, Larry Troxler wrote:
On Sunday 11 January 2004 10:56, Kjetil Svalastog Matheussen wrote:
When using realtime priority on the audio thread, any non-realtime thread shouldn't cause a dropout... At least in linux. Perhaps it can in macosX?
But it doesn't look like you're using a seperate thread at all (?) I'm using pd-0.36-devel still, so maybe things are different now, but if so that would have been quite a radical reworking of PD, to have the message processing be in a seperate thread than the audio.
Gua! I just presumed PD used a seperate thread for audio! Oh, then I understand.
On Monday 05 January 2004 12:10, Michal Seta wrote:
On Mon, 2004-01-05 at 06:15, Kjetil Svalastog Matheussen wrote:
k_guile is a guile PD external.
wow. cool. Common Music within pd is now possible...
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? Does CM really keep it's state between k_quille objects? 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?
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 still have the feeling that I'm missing a very basic point here, or else I am completely misunderstanding what Kjetil is telling me...
Larry
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
-
Dave Phillips -
Frank Barknecht -
Kjetil Svalastog Matheussen -
Larry Troxler -
Michal Seta -
Patrick Pagano