From ahcnz at orcon.net.nz Tue Sep 1 18:11:26 2020 From: ahcnz at orcon.net.nz (adam) Date: Wed, 02 Sep 2020 13:11:26 +1200 Subject: [CM] O.T. compositions In-Reply-To: References: Message-ID: <4c89332893da218f80f54432eae5f7acf3f00e54.camel@orcon.net.nz> Leviathan (circa 1989) certainly warrants multiple listens. https://www.youtube.com/watch?v=UY5ZoDZi0Lk I have the Wergo CD with Bayle and Karpen also and, after reading its liner notes, have always respected and admired this now classic electroacoustic piece. On Mon, 2020-08-31 at 17:57 +0000, James Hearon wrote: > Hi, > > > > > > > > I'm wondering if there are any Schottstaedt compositions available someplace on the net > for listening? > > > > > > > > Regards, > > > Jim > > > > _______________________________________________Cmdist mailing > listCmdist at ccrma.stanford.eduhttps://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Sat Sep 5 13:18:50 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Sat, 05 Sep 2020 13:18:50 -0700 Subject: [CM] Snd 20.7 Message-ID: <0ab99d3d9c31e36e52c73cd0faf700fe@ccrma.stanford.edu> Snd 20.7: Snd: new configuration switch: --with-notcurses; uses nrepl. s7: added emscripten support for webassembly, thanks to Christos Vagias mingw fix thanks to Kjetil checked: gtk 3.99.0|1, OSX 10.15.6, sbcl 2.0.8 Thanks!: Christos Vagias, Kjetil Matheussen From bil at ccrma.Stanford.EDU Mon Sep 7 05:59:47 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Mon, 07 Sep 2020 05:59:47 -0700 Subject: [CM] =?utf-8?q?gtk_in_snd=3F?= Message-ID: Would anyone greatly object if I remove all gtk support from Snd? gtk3 was changing so much and so often that I stopped trying to keep up. gtk4 is turning out to be a disaster. It is a mostly new GUI toolkit based on crap like XML files, and the drawing area handling looks unusable to me, though I haven't dived into it yet. I will support the Motif version indefinitely in any case. From orm.finnendahl at selma.hfmdk-frankfurt.de Mon Sep 7 06:07:10 2020 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Mon, 7 Sep 2020 15:07:10 +0200 Subject: [CM] gtk in snd? In-Reply-To: References: Message-ID: <20200907130710.GB126352@t480s-orm.localdomain> Hi Bill, no objections whatsoever, rather compassion ;-) -- Orm Am Montag, den 07. September 2020 um 05:59:47 Uhr (-0700) schrieb bil at ccrma.Stanford.EDU: > Would anyone greatly object if I remove all gtk support > from Snd? gtk3 was changing so much and so often that > I stopped trying to keep up. gtk4 is turning out to be > a disaster. It is a mostly new GUI toolkit based > on crap like XML files, and the drawing area handling > looks unusable to me, though I haven't dived into it > yet. > > I will support the Motif version indefinitely in any case. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist From chris.actondev at gmail.com Mon Sep 7 15:10:44 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Tue, 8 Sep 2020 00:10:44 +0200 Subject: [CM] Freeing up s7 instances & memory Message-ID: Hi all and happy "new academic year", I stumbled upon a case where I need to create multiple short lived s7 instances (per thread). And I'm seeing the memory consumption getting higher and higher in my application. What happens when we call "free(s7)" (s7 = s7_init) ? >From what I'm seeing.. nothing Consider this snippet, when in every loop I'm creating a c-object pointing to a ~100mb char array. for (int i = 0; i < 10; i++) { s7_scheme *sc = s7_init(); aod::s7::bind_all(sc); // binds the aod.c.foreign s7_eval_c_string(sc, "(define x ((aod.c.foreign 'new-char[]) 100000000))" // ~100 mb ); free(sc); } That memory doesn't get freed. After all the iteration the memory usage will be ~1GB. I think at some point I stumbled upon a comment in the s7 source code that was saying something about this (could me mistaken though) Thanks, Christos -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamennedev at gmail.com Mon Sep 7 15:28:08 2020 From: kamennedev at gmail.com (Kamen Nedev) Date: Tue, 8 Sep 2020 00:28:08 +0200 Subject: [CM] gtk in snd? In-Reply-To: <20200907130710.GB126352@t480s-orm.localdomain> References: <20200907130710.GB126352@t480s-orm.localdomain> Message-ID: Ah, yes, the GTK interface. I remember having trouble with it on my Ubuntu Studio install (18.04). Ubuntu Studio had inherited *buntu's infamous "floating sidebars", which made Snd's controls mostly unusable. It also had a color scheme that made most things in the GUI difficult to read. Or, well, that was the .deb package from the Ubuntu repos. So I remember at some point I decided to compile my own version of Snd, if anything, just to be able to keep up with all the updates I was reading about on this list. Compiling Snd is easy, and fun. Then, still frustrated with the GTK interface, I tried compiling Snd with a Motif interface. Well, guess what, I finally got a lean-and-mean, effective GUI. Never been a fan of Motif, but on Snd, it seems to be the sensible option. So, no, I for one won't be missing the GTK interface. Best, K. On 9/7/20, Orm Finnendahl wrote: > Hi Bill, > > no objections whatsoever, rather compassion ;-) > > -- > Orm > > Am Montag, den 07. September 2020 um 05:59:47 Uhr (-0700) schrieb > bil at ccrma.Stanford.EDU: >> Would anyone greatly object if I remove all gtk support >> from Snd? gtk3 was changing so much and so often that >> I stopped trying to keep up. gtk4 is turning out to be >> a disaster. It is a mostly new GUI toolkit based >> on crap like XML files, and the drawing area handling >> looks unusable to me, though I haven't dived into it >> yet. >> >> I will support the Motif version indefinitely in any case. >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -- (((o))) Kamen Nedev Acoustic Mirror: http://acousticmirror.tumblr.com self/noise: http://self-noise.tumblr.com ./mediateletipos))): http://mediateletipos.net From bil at ccrma.Stanford.EDU Mon Sep 7 16:06:40 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Mon, 07 Sep 2020 16:06:40 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: Message-ID: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> You're right that free(sc) does not free much. Woody Douglass sent me code to free most of s7's memory -- the main thing is the heap -- but I haven't tackled merging it into my version of s7 yet. I think s7 instances can be reused -- just keep all your stuff in a sublet of rootlet, then set it to #f, but it would be better to actually clean up. From chris.actondev at gmail.com Tue Sep 8 02:36:49 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Tue, 8 Sep 2020 11:36:49 +0200 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> Message-ID: Indeed the instances could be reused, but that would imply using a common mutex amongst the running threads for any s7 operation (right?). What I need in my case is truly parallel instances doing their own thing. I'm glad to hear that Woody has some sort of a solution. I hope it gets merged at some point, but I also hope for a solution in the future that frees not most but *all* of s7's memory :) Any chance I could see this code? By curiosity and to see if I could slowly get some understanding of the inner workings of s7. On Tue, 8 Sep 2020 at 01:06, wrote: > You're right that free(sc) does not free much. Woody Douglass > sent me code to free most of s7's memory -- the main thing > is the heap -- but I haven't tackled merging it into my > version of s7 yet. I think s7 instances can be reused -- > just keep all your stuff in a sublet of rootlet, then > set it to #f, but it would be better to actually clean up. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Tue Sep 8 03:52:23 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Tue, 8 Sep 2020 12:52:23 +0200 Subject: [CM] s7_nil behaving as #t Message-ID: (if () 1 2) => returns 1 Similarly with s7_nil (as returned from a c binding) I think s7_nil should behave as #f. Opinions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.s.matheussen at gmail.com Tue Sep 8 04:11:02 2020 From: k.s.matheussen at gmail.com (Kjetil Matheussen) Date: Tue, 8 Sep 2020 13:11:02 +0200 Subject: [CM] s7_nil behaving as #t In-Reply-To: References: Message-ID: On Tue, Sep 8, 2020 at 12:55 PM Christos Vagias wrote: > > (if () 1 2) => returns 1 > > Similarly with s7_nil (as returned from a c binding) > > I think s7_nil should behave as #f. > > Opinions? > There's lots of situations where this would be practical, but since s7 is a Scheme implementation, I think it's probably best to behave as #t to avoid trouble when porting to other scheme implementations. Also, people who knows scheme would be confused if '() returned #f. From orm.finnendahl at selma.hfmdk-frankfurt.de Tue Sep 8 04:24:52 2020 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Tue, 8 Sep 2020 13:24:52 +0200 Subject: [CM] s7_nil behaving as #t In-Reply-To: References: Message-ID: <20200908112452.GB153986@t480s-orm.localdomain> Hi, Am Dienstag, den 08. September 2020 um 13:11:02 Uhr (+0200) schrieb Kjetil Matheussen: > There's lots of situations where this would be practical, but since s7 > is a Scheme implementation, I think it's probably best to behave as #t > to avoid trouble when porting to other scheme implementations. Also, > people who knows scheme would be confused if '() returned #f. Exactly. This is a well known (much discussed) difference between scheme and common lisp (or other dialects) and would break scheme if changed. If you feel adventurous, I'd recommend to overwrite if at the beginning of your code or define a custom macro of a different name which behaves like cl's if for the use cases where you need this behaviour. -- Orm From bil at ccrma.Stanford.EDU Tue Sep 8 05:46:26 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 08 Sep 2020 05:46:26 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> Message-ID: <83314e8cf029a398cab9034d99e7d645@ccrma.stanford.edu> I think you misunderstood my suggestion. It has nothing to do with mutexes or threads. Take repl.scm for example. It has a top-level-let, initially (inlet), or its equivalent (sublet (rootlet)). All evaluation and loading by default takes place in that let, not the rootlet. So: /home/bil/cl/ repl <1> (define x 32) 32 <2> (defined? 'x) #t <3> (defined? 'x (rootlet)) #f <4> (set! (*repl* 'top-level-let) (inlet)) (inlet) <5> (defined? 'x) #f So by resetting top-level-let we're back to the pristine start-up state, just as if we had freed the initial repl and started a new one. There are a few tricky points involving the built-in hooks, but you can save their startup state, and re-establish them when you clear out the top-level-let. In the multi-s7 case, I'd have a pool of s7's. There are no mutexes in s7.c (except some that Kjetil uses for debugging). From bil at ccrma.Stanford.EDU Tue Sep 8 06:02:24 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 08 Sep 2020 06:02:24 -0700 Subject: [CM] =?utf-8?q?gtk_in_snd=3F?= In-Reply-To: References: <20200907130710.GB126352@t480s-orm.localdomain> Message-ID: <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> Yes, Snd's gtk GUI was falling apart in gtk3 -- I stopped using it altogether. Since gtk4 is a new beast, I've managed to rationalize this change: I have to start over, and the current code is not working, so let's get on with it. I'll look at other toolkits first, Juce and Qt in particular. If I may be allowed a digression (us old guys tend to talk too much); in gtk1 and gtk2 the interface was very close to the Motif version, leaving aside the access to openGL in Motif (which I greatly valued for spectrograms etc). In gtk3, (or thereabouts -- my memory is hazy), they decided to go with Cairo instead of openGL, which meant the "G" in "GUI" was at a dead-end. Then smart phones and Wayland came along, and Gnome took over with its notion of a "brand" -- everything must look and act the same. But Snd was aimed at the study of sounds in the context of music composition -- can you imagine a smaller niche? Once upon a time Stanford was going through some "strategic" thrash, and I was asked to go down to the quad (the administrative offices at that time) and talk with someone about how to position the music department for the future, or some equally nebulous jargon. I was so naive I actually tried to dream up some great ideas, then waltzed down to the quad thinking I'd get a confetti parade. The guy I was supposed to meet had his feet on his desk (he mumbled something about a skiing accident), we swapped howdies, and then he asked: "can you justify your position on a cost basis?". I said no, and for the rest of the hour-long interrogation, they got nothing out of me but name, rank, and serial number. So even at Stanford, no one could figure out what I was up to. Who has the resources to support such stuff? From wdouglass at carnegierobotics.com Tue Sep 8 06:19:05 2020 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Tue, 8 Sep 2020 13:19:05 +0000 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu>, Message-ID: Christos, Here's a copy of the patch i put on this list back in May. It's against svn revision 804. I've been running that version since mid-May. Good luck! Woody Douglass On 2020-09-08 09:12:27-04:00 cmdist-bounces at ccrma.Stanford.EDU wrote: Indeed the instances could be reused, but that would imply using a common mutex amongst the running threads for any s7 operation (right?). What I need in my case is truly parallel instances doing their own thing. I'm glad to hear that Woody has some sort of a solution. I hope it gets merged at some point, but I also hope for a solution in the future that frees not most but *all* of s7's memory :) Any chance I could see this code? By curiosity and to see if I could slowly get some understanding of the inner workings of s7. On Tue, 8 Sep 2020 at 01:06, > wrote: You're right that free(sc) does not free much. Woody Douglass sent me code to free most of s7's memory -- the main thing is the heap -- but I haven't tackled merging it into my version of s7 yet. I think s7 instances can be reused -- just keep all your stuff in a sublet of rootlet, then set it to #f, but it would be better to actually clean up. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-s7-cleanup.patch Type: application/octet-stream Size: 13195 bytes Desc: 0001-s7-cleanup.patch URL: From k.s.matheussen at gmail.com Tue Sep 8 06:23:18 2020 From: k.s.matheussen at gmail.com (Kjetil Matheussen) Date: Tue, 8 Sep 2020 15:23:18 +0200 Subject: [CM] gtk in snd? In-Reply-To: <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> Message-ID: I would not recommend Qt at least. It's got lots of strange bugs and peculiar behaviors. SND is so big, that I would actually recommend creating your own widget set, built upon SDL for instance. It will probably save a lot of time if you spend a lot of time fighting against the GUI. You would also save a lot of time if you write the custom widget set in Scheme and not in C. At least this is my experience in Radium, where half of the GUI is written in a custom widget set, and the other half in Qt. Hopefully I will get rid of Qt at some point, at least for GUI and graphics. Writing the code to draw a button doesn't take much time for instance, it's not much more work than a call to paintRoundedRectangle and a call to paintText(). On Tue, Sep 8, 2020 at 3:05 PM wrote: > > Yes, Snd's gtk GUI was falling apart in gtk3 -- I stopped > using it altogether. Since gtk4 is a new beast, I've > managed to rationalize this change: I have to start over, > and the current code is not working, so let's get on with it. > I'll look at other toolkits first, Juce and Qt in particular. > If I may be allowed a digression (us old guys tend to talk > too much); in gtk1 and gtk2 the interface was very close > to the Motif version, leaving aside the access to openGL > in Motif (which I greatly valued for spectrograms etc). > In gtk3, (or thereabouts -- my memory is hazy), they > decided to go with Cairo instead of openGL, which meant > the "G" in "GUI" was at a dead-end. Then smart phones > and Wayland came along, and Gnome took over with its > notion of a "brand" -- everything must look and act the > same. But Snd was aimed at the study of sounds in the > context of music composition -- can you imagine a smaller > niche? Once upon a time Stanford was going through some > "strategic" thrash, and I was asked to go down to the > quad (the administrative offices at that time) and talk > with someone about how to position the music department > for the future, or some equally nebulous jargon. I > was so naive I actually tried to dream up some great > ideas, then waltzed down to the quad thinking I'd get > a confetti parade. The guy I was supposed to meet > had his feet on his desk (he mumbled something about > a skiing accident), we swapped howdies, and then he > asked: "can you justify your position on a cost basis?". > I said no, and for the rest of the hour-long interrogation, > they got nothing out of me but name, rank, and serial number. > So even at Stanford, no one could figure out what I was > up to. Who has the resources to support such stuff? > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist From iainduncanlists at gmail.com Tue Sep 8 06:59:08 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Tue, 8 Sep 2020 06:59:08 -0700 Subject: [CM] s7_nil behaving as #t In-Reply-To: <20200908112452.GB153986@t480s-orm.localdomain> References: <20200908112452.GB153986@t480s-orm.localdomain> Message-ID: Yes, as long as S7 is "mostly r5rs" as the docs state, then *only* #f can evaluate as #f. Nil and 0 both have to evaluate as #f in a boolean context. A bit different but has its uses! Which is why recusing over scheme lists, the base check is usually done with the null? predicate: (null? list-that-might-be-empty :alldone) iain On Tue, Sep 8, 2020 at 4:26 AM Orm Finnendahl < orm.finnendahl at selma.hfmdk-frankfurt.de> wrote: > Hi, > > Am Dienstag, den 08. September 2020 um 13:11:02 Uhr (+0200) schrieb > Kjetil Matheussen: > > There's lots of situations where this would be practical, but since s7 > > is a Scheme implementation, I think it's probably best to behave as #t > > to avoid trouble when porting to other scheme implementations. Also, > > people who knows scheme would be confused if '() returned #f. > > Exactly. This is a well known (much discussed) difference between > scheme and common lisp (or other dialects) and would break scheme if > changed. If you feel adventurous, I'd recommend to overwrite if at the > beginning of your code or define a custom macro of a different name > which behaves like cl's if for the use cases where you need this > behaviour. > > -- > Orm > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Tue Sep 8 07:03:33 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Tue, 8 Sep 2020 07:03:33 -0700 Subject: [CM] gtk in snd? In-Reply-To: References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> Message-ID: I've done some QT, JUCE, FLTK, and WxWidgets. My opinion after doing this is that it's a good idea to keep any external gui dependencies very tightly controlled. As in get at them through an adapter layer or something so that you rip them out easily enough or compile optionally with one or the other. They have a nasty habit of changing direction dramatically every five years or whatever, or being purchased and changing licenses. :-/ my two cents canadian iain On Tue, Sep 8, 2020 at 6:23 AM Kjetil Matheussen wrote: > I would not recommend Qt at least. It's got lots of strange bugs and > peculiar behaviors. SND is so big, that I would actually recommend > creating your own widget set, built upon SDL for instance. It will > probably save a lot of time if you spend a lot of time fighting > against the GUI. You would also save a lot of time if you write the > custom widget set in Scheme and not in C. At least this is my > experience in Radium, where half of the GUI is written in a custom > widget set, and the other half in Qt. Hopefully I will get rid of Qt > at some point, at least for GUI and graphics. Writing the code to draw > a button doesn't take much time for instance, it's not much more work > than a call to paintRoundedRectangle and a call to paintText(). > > > On Tue, Sep 8, 2020 at 3:05 PM wrote: > > > > Yes, Snd's gtk GUI was falling apart in gtk3 -- I stopped > > using it altogether. Since gtk4 is a new beast, I've > > managed to rationalize this change: I have to start over, > > and the current code is not working, so let's get on with it. > > I'll look at other toolkits first, Juce and Qt in particular. > > If I may be allowed a digression (us old guys tend to talk > > too much); in gtk1 and gtk2 the interface was very close > > to the Motif version, leaving aside the access to openGL > > in Motif (which I greatly valued for spectrograms etc). > > In gtk3, (or thereabouts -- my memory is hazy), they > > decided to go with Cairo instead of openGL, which meant > > the "G" in "GUI" was at a dead-end. Then smart phones > > and Wayland came along, and Gnome took over with its > > notion of a "brand" -- everything must look and act the > > same. But Snd was aimed at the study of sounds in the > > context of music composition -- can you imagine a smaller > > niche? Once upon a time Stanford was going through some > > "strategic" thrash, and I was asked to go down to the > > quad (the administrative offices at that time) and talk > > with someone about how to position the music department > > for the future, or some equally nebulous jargon. I > > was so naive I actually tried to dream up some great > > ideas, then waltzed down to the quad thinking I'd get > > a confetti parade. The guy I was supposed to meet > > had his feet on his desk (he mumbled something about > > a skiing accident), we swapped howdies, and then he > > asked: "can you justify your position on a cost basis?". > > I said no, and for the rest of the hour-long interrogation, > > they got nothing out of me but name, rank, and serial number. > > So even at Stanford, no one could figure out what I was > > up to. Who has the resources to support such stuff? > > > > _______________________________________________ > > Cmdist mailing list > > Cmdist at ccrma.stanford.edu > > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nando at ccrma.Stanford.EDU Tue Sep 8 10:34:32 2020 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Tue, 8 Sep 2020 10:34:32 -0700 Subject: [CM] gtk in snd? In-Reply-To: References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> Message-ID: <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> On 9/8/20 6:23 AM, Kjetil Matheussen wrote: > I would not recommend Qt at least. It's got lots of strange bugs and > peculiar behaviors. SND is so big, that I would actually recommend > creating your own widget set, built upon SDL for instance. It will > probably save a lot of time if you spend a lot of time fighting > against the GUI. I believe that is probably what Fons (Adriaensen) did for his software, he wrote is own widget set layered directly on top of X (in C++) - I don't know why he did that, but it may be the same reason. It is available as a library here: https://kokkinizita.linuxaudio.org/linuxaudio/downloads/clxclient-3.9.2.tar.bz2 -- Fernando > You would also save a lot of time if you write the > custom widget set in Scheme and not in C. At least this is my > experience in Radium, where half of the GUI is written in a custom > widget set, and the other half in Qt. Hopefully I will get rid of Qt > at some point, at least for GUI and graphics. Writing the code to draw > a button doesn't take much time for instance, it's not much more work > than a call to paintRoundedRectangle and a call to paintText(). > > > On Tue, Sep 8, 2020 at 3:05 PM wrote: >> >> Yes, Snd's gtk GUI was falling apart in gtk3 -- I stopped >> using it altogether. Since gtk4 is a new beast, I've >> managed to rationalize this change: I have to start over, >> and the current code is not working, so let's get on with it. >> I'll look at other toolkits first, Juce and Qt in particular. >> If I may be allowed a digression (us old guys tend to talk >> too much); in gtk1 and gtk2 the interface was very close >> to the Motif version, leaving aside the access to openGL >> in Motif (which I greatly valued for spectrograms etc). >> In gtk3, (or thereabouts -- my memory is hazy), they >> decided to go with Cairo instead of openGL, which meant >> the "G" in "GUI" was at a dead-end. Then smart phones >> and Wayland came along, and Gnome took over with its >> notion of a "brand" -- everything must look and act the >> same. But Snd was aimed at the study of sounds in the >> context of music composition -- can you imagine a smaller >> niche? ... From bil at ccrma.Stanford.EDU Wed Sep 9 07:04:59 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 09 Sep 2020 07:04:59 -0700 Subject: [CM] =?utf-8?q?gtk_in_snd=3F?= In-Reply-To: <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> Message-ID: <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> That is interesting -- thanks for the pointer! I wonder if writing raw X code is a good idea -- people say Wayland is the future (but they've been saying that for a decade). I don't know how toolkits like gtk work with it -- that was one reason to stick with gtk for so long. From cm at jrigg.co.uk Wed Sep 9 08:14:17 2020 From: cm at jrigg.co.uk (John Rigg) Date: Wed, 9 Sep 2020 15:14:17 +0000 Subject: [CM] gtk in snd? In-Reply-To: References: Message-ID: <20200909151417.GA27692@localhost.localdomain> On Mon, Sep 07, 2020 at 05:59:47AM -0700, bil at ccrma.Stanford.EDU wrote: > Would anyone greatly object if I remove all gtk support > from Snd? No objection here. I've always used the Motif version. John From k.s.matheussen at gmail.com Wed Sep 9 08:25:58 2020 From: k.s.matheussen at gmail.com (Kjetil Matheussen) Date: Wed, 9 Sep 2020 17:25:58 +0200 Subject: [CM] gtk in snd? In-Reply-To: <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> Message-ID: On Wed, Sep 9, 2020 at 4:05 PM wrote: > > That is interesting -- thanks for the pointer! I wonder > if writing raw X code is a good idea -- people say Wayland > is the future (but they've been saying that for a decade). > I don't know how toolkits like gtk work with it -- that > was one reason to stick with gtk for so long. I would say raw X (or Wayland) is a bad idea since it would mostly limit Snd to run on Linux only. If you want to make your own widgets, and only need a canvas to draw on, gdk, SDL, or JUCE might be good alternatives (haven't tried SDL though). Or cairo? From cm at jrigg.co.uk Wed Sep 9 09:17:00 2020 From: cm at jrigg.co.uk (John Rigg) Date: Wed, 9 Sep 2020 16:17:00 +0000 Subject: [CM] gtk in snd? In-Reply-To: <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> Message-ID: <20200909161700.GB27692@localhost.localdomain> On Wed, Sep 09, 2020 at 07:04:59AM -0700, bil at ccrma.Stanford.EDU wrote: > That is interesting -- thanks for the pointer! I wonder > if writing raw X code is a good idea -- people say Wayland > is the future (but they've been saying that for a decade). Several Linux audio developers have moved away from big GUI toolkits like GTK in the last few years. OpenGL and Cairo seem quite popular. Robin Gareus wrote his own toolkit for x42-plugins: https://github.com/x42/robtk The LSP-Plugins project switched from GTK to their own toolkit: https://github.com/sadko4u/lsp-plugins J. Liles, the developer of Non DAW made his own port of FLTK (NTK) with Cairo support: https://github.com/original-male/ntk John From chris.actondev at gmail.com Wed Sep 9 16:04:52 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Thu, 10 Sep 2020 01:04:52 +0200 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> Message-ID: Thanks Woody! The patch seems pretty straight forward, I might have a go with it at some point. Certainly though help with some understanding of s7 internals :) I do hope Bil gets to merge this (or some other version of it) cause maintaining changes & merging the upstream.. ughh.. Oh and found your original post in the mailing list: https://www.mail-archive.com/cmdist at ccrma.stanford.edu/msg05320.html (bonus: the list is searchable through mail-archive! nice thing it became public) On Tue, 8 Sep 2020 at 15:18, Woody Douglass wrote: > Christos, > > Here's a copy of the patch i put on this list back in May. It's against > svn revision 804. I've been running that version since mid-May. > > Good luck! > Woody Douglass > > > > On 2020-09-08 09:12:27-04:00 cmdist-bounces at ccrma.Stanford.EDU wrote: > > Indeed the instances could be reused, but that would imply > using a common mutex amongst the running threads for any > s7 operation (right?). > What I need in my case is truly parallel instances doing their own thing. > I'm glad to hear that Woody has some sort of a solution. > I hope it gets merged at some point, but I also hope for a solution > in the future that frees not most but *all* of s7's memory :) > Any chance I could see this code? By curiosity and to see if I could > slowly get some understanding of the inner workings of s7. > > On Tue, 8 Sep 2020 at 01:06, wrote: > >> You're right that free(sc) does not free much. Woody Douglass >> sent me code to free most of s7's memory -- the main thing >> is the heap -- but I haven't tackled merging it into my >> version of s7 yet. I think s7 instances can be reused -- >> just keep all your stuff in a sublet of rootlet, then >> set it to #f, but it would be better to actually clean up. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Wed Sep 9 20:48:06 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Wed, 9 Sep 2020 20:48:06 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> Message-ID: > > > I do hope Bil gets to merge this (or some other version of it) cause > maintaining changes & merging the upstream.. ughh.. > Presumably this wouldn't be too bad if you used Woody's git mirror and rebased it over your own git branch? We used that approach at my old job and it the nice thing is rebasing the moving master into your local branch means the merge (and any conflicts) is always in the local branch and it's easier to back out of. This may be old hat to you, but figured I'd mention it case it isn't. :-) We did - cut feature branch, work away privately while master gets changed by others - when done, rebase updated master on to local branch, so your local changes get replayed over the new master - then merge local branch into master, which is really just cosmetic as they are identical at that point Git can be a pain sometimes, but man, it's good at merges compared to SVN. Freaking magical. iain > > Oh and found your original post in the mailing list: > https://www.mail-archive.com/cmdist at ccrma.stanford.edu/msg05320.html > (bonus: the list is searchable through mail-archive! nice thing it became > public) > > On Tue, 8 Sep 2020 at 15:18, Woody Douglass < > wdouglass at carnegierobotics.com> wrote: > >> Christos, >> >> Here's a copy of the patch i put on this list back in May. It's against >> svn revision 804. I've been running that version since mid-May. >> >> Good luck! >> Woody Douglass >> >> >> >> On 2020-09-08 09:12:27-04:00 cmdist-bounces at ccrma.Stanford.EDU wrote: >> >> Indeed the instances could be reused, but that would imply >> using a common mutex amongst the running threads for any >> s7 operation (right?). >> What I need in my case is truly parallel instances doing their own thing. >> I'm glad to hear that Woody has some sort of a solution. >> I hope it gets merged at some point, but I also hope for a solution >> in the future that frees not most but *all* of s7's memory :) >> Any chance I could see this code? By curiosity and to see if I could >> slowly get some understanding of the inner workings of s7. >> >> On Tue, 8 Sep 2020 at 01:06, wrote: >> >>> You're right that free(sc) does not free much. Woody Douglass >>> sent me code to free most of s7's memory -- the main thing >>> is the heap -- but I haven't tackled merging it into my >>> version of s7 yet. I think s7 instances can be reused -- >>> just keep all your stuff in a sublet of rootlet, then >>> set it to #f, but it would be better to actually clean up. >>> >> >> _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Sep 10 02:53:27 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 10 Sep 2020 02:53:27 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> Message-ID: <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> I have started merging Woody's code -- s7_free in the current tarball. This will not be done overnight. Thanks for the pointer to mail-archive -- I'll check it out later today. From lb at zkm.de Wed Sep 9 09:11:53 2020 From: lb at zkm.de (=?utf-8?Q?ludger_br=C3=BCmmer?=) Date: Wed, 9 Sep 2020 18:11:53 +0200 Subject: [CM] gtk in snd? In-Reply-To: References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> Message-ID: <876DF174-FC3E-4E6D-9392-FE4E8ED0754C@zkm.de> Hi all don?t know If I am the only OSX user here, but, being not an experienced coder, I tried to compile SND with motif on OSX several time over the last years and most of the time it failed. I got only GTK to run. So I would be happy if the solution you will find could work on OSX without having a good recommendation for a specific system myself. viele Gr??e / all the best Ludger Br?mmer -- Prof. Ludger Br?mmer Leitung | Head of Department Hertz-Labor | Hertz-Lab Professor f?r Komposition f?r digitale Medien Musikhochschule Trossingen, mh-trossingen.de /////// / |< ||| | ZKM | Zentrum f?r Kunst und Medien Karlsruhe /////// / |< ||| | ZKM | Center for Art and Media Karlsruhe /////// / |< ||| | ZKM | Centre d'Art et des M?dias Karlsruhe Lorenzstr. 19, D-76135 Karlsruhe Tel +49-(0)721-8100-1601, Fax +49-(0)721-8100-1699 E-Mail: ludger.bruemmer at zkm.de www.zkm.de Aktuelle Ausstellungen ? current exhibitions > Am 09.09.2020 um 17:25 schrieb Kjetil Matheussen : > > On Wed, Sep 9, 2020 at 4:05 PM wrote: >> >> That is interesting -- thanks for the pointer! I wonder >> if writing raw X code is a good idea -- people say Wayland >> is the future (but they've been saying that for a decade). >> I don't know how toolkits like gtk work with it -- that >> was one reason to stick with gtk for so long. > > I would say raw X (or Wayland) is a bad idea since it would mostly > limit Snd to run on Linux only. If you want to make your own widgets, > and only need a canvas to draw on, gdk, SDL, or JUCE might be good > alternatives (haven't tried SDL though). Or cairo? > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zkm-cz.jpg Type: image/jpeg Size: 41457 bytes Desc: not available URL: From k.s.matheussen at gmail.com Thu Sep 10 03:00:47 2020 From: k.s.matheussen at gmail.com (Kjetil Matheussen) Date: Thu, 10 Sep 2020 12:00:47 +0200 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> Message-ID: There is an alternative too. Instead of letting the user of s7 handle a pool of s7 instances, s7 could handle this pool itself so that s7_release (or s7_free) put the instance into this pool, and then s7_init would use this pool if possible. Wouldn't always be an acceptable solution, but maybe it's good enough. On Thu, Sep 10, 2020 at 11:56 AM wrote: > > I have started merging Woody's code -- s7_free in the current > tarball. This will not be done overnight. Thanks for the > pointer to mail-archive -- I'll check it out later today. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist From chris.actondev at gmail.com Thu Sep 10 03:30:02 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Thu, 10 Sep 2020 12:30:02 +0200 Subject: [CM] Let with list destructuring Message-ID: Hi all, Wanted to share with you a macro I wrote about let (and let*) with list destructuring. Something similar to the destructuring-bind as seen in stuff.scm I missed this functionality from clojure. Example usage: ;; letd: mnemonic: let-destructure (letd ((a 1) (b 2) ((c d) (list (+ 1 2) 4))) (list a b c d )) ;; => (1 2 3 4) (letd* ((a 1) (b 2) ((c d) (list (+ 1 2) 4)) (e (+ 1 d))) (list a b c d e)) ;; => ;; (1 2 3 4 5) Note: clojure also has destructuring for maps etc. Didn't have this need yet, but guess the macro could be modified to accommodate destructuring hashmaps, inlets etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s7-let-destructuring.scm Type: text/x-scheme Size: 1845 bytes Desc: not available URL: From bil at ccrma.Stanford.EDU Thu Sep 10 03:59:23 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 10 Sep 2020 03:59:23 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> Message-ID: Hmmm -- let me think about that -- I already have a "shadow_rootlet" that masquerades as rootlet (for FFI writers' convenience). From chris.actondev at gmail.com Thu Sep 10 04:26:56 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Thu, 10 Sep 2020 13:26:56 +0200 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> Message-ID: Some context about my scenario, where only the proper "free" will work. I made some small skeleton for making VST3 applications with s7 doing the DSP & GUI (using iPlug2 framework & Dear ImGui for the graphics). Normal scenario: The DAW host loads my dynamic library and whenever a user adds an instance of this VST, a new s7 instance is created. (well and one more for the GUI, cause it runs in a separate thread). So we have 2 s7 instances per.. plugin instance. Now, when a user adds a new instance of the plugin, 2 more s7 instances will be initiated. One thing to note here: globals are shared amongst these plugin instances. So indeed, a pool of s7 instances could work: when removing a plugin, 2 s7 instances are freed (the dsp and gui). Then, when the user adds a new plugin, these 2 instances of the pool could be reused. The memory keeps growing though (has to do with the max loaded plugin instances) However: It's possible that the DAW runs the plugin sandboxed in a separate process. That means globals are not shared, and the s7 instances pool cannot work. The memory keeps growing even more quickly in this scenario. Sorry for insisting a lot on this. At the moment even with the worst case scenario of memory growing it's fine, cause these VSTs plugins are only a playground for me. But if this project were to be something used by others, this memory leaking is a deal-breaker. PS If anyone is interested in this (VST3 with S7) feel free to contact me (I have the repo private still). And hopefully they could help with either code or advice :) On Thu, 10 Sep 2020 at 12:59, wrote: > Hmmm -- let me think about that -- I already have a > "shadow_rootlet" that masquerades as rootlet (for > FFI writers' convenience). > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Sep 10 05:35:33 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 10 Sep 2020 05:35:33 -0700 Subject: [CM] =?utf-8?q?gtk_in_snd=3F?= In-Reply-To: <20200909161700.GB27692@localhost.localdomain> References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> <20200909161700.GB27692@localhost.localdomain> Message-ID: <80003223928d16110adc74f96022a05d@ccrma.stanford.edu> Those 3 projects look like what I need, but only the lsp-plugins appears to be active. cairo apparently works on the Mac, via homebrew (which I don't trust -- it made an unholy mess of my Mac a few years ago). Thanks for the pointers -- my TODO list is rapidly growing! From iainduncanlists at gmail.com Thu Sep 10 07:30:40 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 10 Sep 2020 07:30:40 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> Message-ID: HI Christos, I'd love to look at the repo if you're able to add me as a viewer. I'm iainctduncan on github. I look forward to seeing it in action! On Thu, Sep 10, 2020 at 4:27 AM Christos Vagias wrote: > Some context about my scenario, where only the proper "free" will work. > > I made some small skeleton for making VST3 applications with s7 doing the > DSP & GUI (using iPlug2 > framework & Dear ImGui for the graphics). > > Normal scenario: > The DAW host loads my dynamic library and whenever a user adds an instance > of this VST, a new > s7 instance is created. (well and one more for the GUI, cause it runs in a > separate thread). > So we have 2 s7 instances per.. plugin instance. > > Now, when a user adds a new instance of the plugin, 2 more s7 instances > will be initiated. > One thing to note here: globals are shared amongst these plugin instances. > So indeed, a pool of s7 instances could work: when removing a plugin, 2 s7 > instances are freed (the dsp and gui). > Then, when the user adds a new plugin, these 2 instances of the pool could > be reused. > The memory keeps growing though (has to do with the max loaded plugin > instances) > > However: > It's possible that the DAW runs the plugin sandboxed in a separate process. > That means globals are not shared, and the s7 instances pool cannot work. > The memory keeps growing even more quickly in this scenario. > > Sorry for insisting a lot on this. > At the moment even with the worst case scenario of memory growing it's > fine, cause these VSTs plugins are > only a playground for me. > But if this project were to be something used by others, this memory > leaking is a deal-breaker. > > PS > If anyone is interested in this (VST3 with S7) feel free to contact me (I > have the repo private still). > And hopefully they could help with either code or advice :) > > On Thu, 10 Sep 2020 at 12:59, wrote: > >> Hmmm -- let me think about that -- I already have a >> "shadow_rootlet" that masquerades as rootlet (for >> FFI writers' convenience). >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Thu Sep 10 07:35:19 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 10 Sep 2020 07:35:19 -0700 Subject: [CM] Let with list destructuring In-Reply-To: References: Message-ID: Nice, thanks for sharing this! I will certainly add it to my base S7 files for scheme-for-max! I have been meaning to port over Clojure's thread-first and thread-last macros but haven't got to it yet as we are in the process of trying to buy and sell a house and move. Which to the surprise of no one who's done it, I'm sure, is vastly more time consuming than I expected. Ugh. :-/ thanks for sharing it iain On Thu, Sep 10, 2020 at 3:30 AM Christos Vagias wrote: > Hi all, > > Wanted to share with you a macro I wrote about let (and let*) with > list destructuring. Something similar to the destructuring-bind as seen > in stuff.scm > I missed this functionality from clojure. > > Example usage: > > ;; letd: mnemonic: let-destructure > (letd ((a 1) > (b 2) > ((c d) (list (+ 1 2) 4))) > (list a b c d )) > ;; => (1 2 3 4) > > (letd* ((a 1) > (b 2) > ((c d) (list (+ 1 2) 4)) > (e (+ 1 d))) > (list a b c d e)) > ;; => ;; (1 2 3 4 5) > > Note: clojure also has destructuring for maps etc. Didn't have this need > yet, > but guess the macro could be modified to accommodate destructuring > hashmaps, inlets etc. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tito.01beta at gmail.com Thu Sep 10 08:13:43 2020 From: tito.01beta at gmail.com (Tito Latini) Date: Thu, 10 Sep 2020 17:13:43 +0200 Subject: [CM] Snd/CLM: experimental version of src and src-channel Message-ID: <20200910151343.GA2948@vis.roboris> Hi, the attached short patch changes mus_src() and mus_src_to_buffer() in snd/clm.c. Probably it is compatible with clm-5/clm.c (no tested). It seems good with constant rates or envelopes. The aliasing is remarkably reduced and the amplitude of the resampled sound is very good. The conversion is performed through the convolution between the input, upsampled by rate, and the polyphase filters obtained from the windowed sinc table. The delay between the polyphase filters is not one sample, but it depends on the rate. For example, if rate is 1.9, the phase shift is pi/5: 2 pi (1 - frac(1.9)) = 2 pi 0.1 = pi/5 therefore the index of the first coefficient for the next polyphase filter is SINC-TABLE-DENSITY * 0.1 = 2000 * 0.1 = 200 In practice, sinc_loc (the table index) and sinc_incr are reduced to sinc_loc = SRC_SINC_DENSITY * (1 - srpx) + 4; sinc_incr = SRC_SINC_DENSITY; The increment sinc_incr is the consequence of the polyphase filtering: a coefficient after (SRC_SINC_DENSITY - 1) zeroes. I'm getting also better results with a Kaiser window (not a surprise). It is possible to apply that window if a window parameter, for example window-beta, is set for make-src (not in patch), otherwise the default remains the Hanning window. Kaiser window is not particularly interesting with the current implementation (but we increase the table length), because a compressed interpoled sinc for non-integer rates >1 doesn't start where the window begins, so the sinc is often truncated). On the contrary, the index of a polyphase filter is always near the left side (less than SRC_SINC_DENSITY in the upsampled FIR). What do you think? -------------- next part -------------- --- snd/clm.c~ 2020-09-10 16:06:48.774551471 +0200 +++ snd/clm.c 2020-09-10 16:05:39.163555210 +0200 @@ -13298,8 +13298,8 @@ mus_float_t mus_src(mus_any *srptr, mus_float_t sr_change, mus_float_t (*input)(void *arg, int direction)) { sr *srp = (sr *)srptr; - mus_float_t sum, zf, srx, factor; - int lim, loc, xi; + mus_float_t sum, srx; + int lim, loc; bool int_ok; mus_float_t *data, *sinc_table; @@ -13351,9 +13351,10 @@ if (srx < 0.0) srx = -srx; if (srx > 1.0) { - factor = 1.0 / srx; + mus_float_t zf; + int xi; /* this is not exact since we're sampling the sinc and so on, but it's close over a wide range */ - zf = factor * (mus_float_t)SRC_SINC_DENSITY; + zf = SRC_SINC_DENSITY / srx; xi = (int)(zf + 0.5); /* (let ((e (make-env '(0 1 1 1.1) :length 11))) (src-channel e)) @@ -13363,20 +13364,16 @@ } else { - factor = 1.0; - zf = (mus_float_t)SRC_SINC_DENSITY; - xi = SRC_SINC_DENSITY; int_ok = true; } sum = 0.0; if (int_ok) { - int sinc_loc, sinc_incr, last, last10, xs; + int sinc_loc, sinc_incr, last, last10; - xs = (int)(zf * (srp->width_1 - srp->x)); - sinc_loc = xs + srp->sinc4; - sinc_incr = xi; + sinc_loc = SRC_SINC_DENSITY - (int)(SRC_SINC_DENSITY * srp->x) + 4; + sinc_incr = SRC_SINC_DENSITY; last = loc + lim; last10 = last - 10; @@ -13398,12 +13395,11 @@ } else { - mus_float_t sinc_loc, sinc_incr, x; + mus_float_t sinc_loc, sinc_incr; int last, last10; - x = zf * (srp->width_1 - srp->x); - sinc_loc = x + srp->sinc4; - sinc_incr = zf; + sinc_loc = SRC_SINC_DENSITY * (1 - srp->x) + 4; + sinc_incr = SRC_SINC_DENSITY; last = loc + lim; last10 = last - 10; @@ -13426,7 +13422,7 @@ } srp->x += srx; - return(sum * factor); + return(sum); } @@ -13435,8 +13431,8 @@ /* sr_change = 0.0 */ sr *srp = (sr *)srptr; - mus_float_t x, zf, srx, factor, sincx, srpx; - int lim, i, xi, xs, dir = 1; + mus_float_t srx, sincx, srpx; + int lim, i, dir = 1; bool int_ok; mus_long_t k; mus_float_t *data, *sinc_table; @@ -13454,17 +13450,15 @@ } if (srx > 1.0) { - factor = 1.0 / srx; + mus_float_t zf; + int xi; /* this is not exact since we're sampling the sinc and so on, but it's close over a wide range */ - zf = factor * sincx; - xi = (int)zf; + zf = sincx / srx; + xi = (int)(zf + 0.5); if (fabs((xi - zf) * lim) > 2.0) int_ok = false; else int_ok = true; } else { - factor = 1.0; - zf = sincx; - xi = SRC_SINC_DENSITY; int_ok = true; } @@ -13502,10 +13496,9 @@ if (int_ok) { int sinc_loc, sinc_incr, last, last10; - - xs = (int)(zf * (srp->width_1 - srpx)); - sinc_loc = xs + srp->sinc4; - sinc_incr = xi; + + sinc_loc = SRC_SINC_DENSITY - (int)(SRC_SINC_DENSITY * srpx) + 4; + sinc_incr = SRC_SINC_DENSITY; last = loc + lim; last10 = last - 10; @@ -13529,10 +13522,9 @@ { mus_float_t sinc_loc, sinc_incr; int last, last10; - - x = zf * (srp->width_1 - srpx); - sinc_loc = x + srp->sinc4; - sinc_incr = zf; + + sinc_loc = SRC_SINC_DENSITY * (1 - srpx) + 4; + sinc_incr = SRC_SINC_DENSITY; last = loc + lim; last10 = last - 10; @@ -13554,7 +13546,7 @@ sum += data[loc] * sinc_table[(int)sinc_loc]; } srpx += srx; - out_data[k] = sum * factor; + out_data[k] = sum; } srp->x = srpx; } From bil at ccrma.Stanford.EDU Thu Sep 10 11:06:01 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 10 Sep 2020 11:06:01 -0700 Subject: [CM] Snd/CLM: experimental version of src and src-channel In-Reply-To: <20200910151343.GA2948@vis.roboris> References: <20200910151343.GA2948@vis.roboris> Message-ID: <2f2853d264e21852ef1f9f86a53cbc85@ccrma.stanford.edu> Thanks! I see only a subtle difference -- do you have a (hopefully small) test case? (Am I right that your version is more consistent with the sinc_table initialization? It's been a long time since I looked at this code). I've merged your changes in, but kept the old way under a compile-time switch so it's easy to move back and forth. I'll update the ccrma versions tomorrow morning. From squarewave at elisanet.fi Thu Sep 10 17:13:41 2020 From: squarewave at elisanet.fi (Matti Koskinen) Date: Fri, 11 Sep 2020 03:13:41 +0300 Subject: [CM] gtk in snd? In-Reply-To: <876DF174-FC3E-4E6D-9392-FE4E8ED0754C@zkm.de> References: <20200907130710.GB126352@t480s-orm.localdomain> <41e1426475196fe7a02fcc02cd4b7c1a@ccrma.stanford.edu> <3d4caf10-0ce0-0605-d2c4-ecec0e9c5aa7@ccrma.stanford.edu> <77ec6dea3539ae2f0b576aa0d9a765d8@ccrma.stanford.edu> <876DF174-FC3E-4E6D-9392-FE4E8ED0754C@zkm.de> Message-ID: I got snd + motif working on macOS Catalina. I installed homebrew openmotif and Mac xorg X . Then this was my ./configure CFLAGS='-I/usr/X11/include' LDFLAGS='-L/usr/X11/lib' ./configure --with-motif --with-x And snd got build without errors. Adding homebrew vorbis-tools, mpg123, mpg321 nade snd even happier. Fftw3 I had already, flac also. Misleading was, that these were completely ignored, so I ended up on X-error X features: --x-includes=DIR X include files are in DIR --x-libraries=DIR X library files are in DIR HTH -n > On 9. Sep 2020, at 19.11, ludger br?mmer wrote: > > Hi all > > don?t know If I am the only OSX user here, but, being not an experienced coder, I tried to compile SND with motif on OSX several time over the last years and most of the time it failed. I got only GTK to run. So I would be happy if the solution you will find could work on OSX without having a good recommendation for a specific system myself. > > > viele Gr??e / all the best > Ludger Br?mmer > > -- > Prof. Ludger Br?mmer > Leitung | Head of Department > Hertz-Labor | Hertz-Lab > > Professor f?r Komposition f?r digitale Medien > Musikhochschule Trossingen, mh-trossingen.de > > /////// / |< ||| | ZKM | Zentrum f?r Kunst und Medien Karlsruhe > /////// / |< ||| | ZKM | Center for Art and Media Karlsruhe > /////// / |< ||| | ZKM | Centre d'Art et des M?dias Karlsruhe > > Lorenzstr. 19, D-76135 Karlsruhe > Tel +49-(0)721-8100-1601, Fax +49-(0)721-8100-1699 > E-Mail: ludger.bruemmer at zkm.de > www.zkm.de > > > > Aktuelle Ausstellungen ? current exhibitions > >> Am 09.09.2020 um 17:25 schrieb Kjetil Matheussen >: >> >> On Wed, Sep 9, 2020 at 4:05 PM > wrote: >>> >>> That is interesting -- thanks for the pointer! I wonder >>> if writing raw X code is a good idea -- people say Wayland >>> is the future (but they've been saying that for a decade). >>> I don't know how toolkits like gtk work with it -- that >>> was one reason to stick with gtk for so long. >> >> I would say raw X (or Wayland) is a bad idea since it would mostly >> limit Snd to run on Linux only. If you want to make your own widgets, >> and only need a canvas to draw on, gdk, SDL, or JUCE might be good >> alternatives (haven't tried SDL though). Or cairo? >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: From tito.01beta at gmail.com Fri Sep 11 01:25:15 2020 From: tito.01beta at gmail.com (Tito Latini) Date: Fri, 11 Sep 2020 10:25:15 +0200 Subject: [CM] Snd/CLM: experimental version of src and src-channel In-Reply-To: <2f2853d264e21852ef1f9f86a53cbc85@ccrma.stanford.edu> References: <20200910151343.GA2948@vis.roboris> <2f2853d264e21852ef1f9f86a53cbc85@ccrma.stanford.edu> Message-ID: <20200911082515.GA1702@vis.roboris> On Thu, Sep 10, 2020 at 11:06:01AM -0700, bil at ccrma.Stanford.EDU wrote: > Thanks! I see only a subtle difference -- do you have > a (hopefully small) test case? (Am I right that your > version is more consistent with the sinc_table initialization? > It's been a long time since I looked at this code). > I've merged your changes in, but kept the old way under > a compile-time switch so it's easy to move back and forth. > I'll update the ccrma versions tomorrow morning. Currently I have just some examples with sound files and sinusoids, to check aliasing and amplitude. I think the resampler is correct if the changed code passes all the tests for the original src and src-channel. This message for the mailing list is also an informal test for some user code. About the consistence with the sinc_table initialization: the weak point of the original version is the table index with non-integer high rates: x = zf * (srp->width_1 - srpx); sinc_loc = x + srp->sinc4; It means: /* * Memo: `width' is half length. It originally was the width * of half sinc (the right side). */ L = SRC_SINC_DENSITY; x = L * (1 - width - frac(rate)) / rate; table_index = x + L * width + padding; ==> k = padding + L * (1 - frac(rate)) table_index = L * width * (1 - 1/rate) + k; If the non-integer rate >1 is near 1, the first table index is low and the interpolated sinc is windowed (the approximation depends on rate), otherwise... lim L * width * (1 - 1/rate) = L * width [= main_lobe_peak] rate -> inf ...the sinc is truncated with high values of rate. The first index in the new version is L * (1 - frac(rate)) + padding; The range is [padding; L + padding]. Padding is necessary with the original version. Note: the sinc() begins at the index 0 of the table but the window starts at index `padding'. The window is interpolated, but I think it is possible to remove the interpolation for low values of `width'; however that's a minor optimization without considerable enhancements. Kaiser window with adjustable parameter makes the difference. From tito.01beta at gmail.com Fri Sep 11 03:33:23 2020 From: tito.01beta at gmail.com (Tito Latini) Date: Fri, 11 Sep 2020 12:33:23 +0200 Subject: [CM] Snd/CLM: experimental version of src and src-channel In-Reply-To: <2f2853d264e21852ef1f9f86a53cbc85@ccrma.stanford.edu> References: <20200910151343.GA2948@vis.roboris> <2f2853d264e21852ef1f9f86a53cbc85@ccrma.stanford.edu> Message-ID: <20200911103323.GA4772@vis.roboris> Hey Bill, a copy-and-paste failed in svn. Attached a fix. From danielhensel at me.com Fri Sep 11 04:01:49 2020 From: danielhensel at me.com (DR. Daniel Hensel) Date: Fri, 11 Sep 2020 13:01:49 +0200 Subject: [CM] Cmdist Digest, Vol 148, Issue 14 In-Reply-To: References: Message-ID: <452FC67F-F83C-43C9-A53D-FAF8B17156CA@me.com> gtk in snd? Matti, On my Mac-Systems Fftw is only recognised when the port fftw-single is installed: sudo port install fftw-single One needs to specify the Architecture to get rid of the X-error: This works for me: ./configure -prefix=/opt/snd-s7 CFLAGS="-arch x86_64 -I/opt/X11/include" LDFLAGS="-L/opt/X11/lib -lmx -bind_at_load" -with-gsl -with-gtk -with-s7 I personally cannot recommend to work with it on macOS anymore, due to increasing audio-latency and fading X11-support. On macOS Big Sur I?ll use it in a virtual Linux-machine, so I won?t have to mess with homebrew and Macports. All the best, Daniel > Am 11.09.2020 um 12:27 schrieb cmdist-request at ccrma.stanford.edu : > > Send Cmdist mailing list submissions to > cmdist at ccrma.stanford.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > or, via email, send a message with subject or body 'help' to > cmdist-request at ccrma.stanford.edu > > You can reach the person managing the list at > cmdist-owner at ccrma.stanford.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cmdist digest..." > > > Today's Topics: > > 1. Re: gtk in snd? (Matti Koskinen) > 2. Re: Snd/CLM: experimental version of src and src-channel > (Tito Latini) > 3. Re: Snd/CLM: experimental version of src and src-channel > (Tito Latini) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 11 Sep 2020 03:13:41 +0300 > From: Matti Koskinen > To: ludger br?mmer > Cc: commonmusic-Mailing-List List > Subject: Re: [CM] gtk in snd? > Message-ID: > Content-Type: text/plain; charset="utf-8" > > I got snd + motif working on macOS Catalina. > > I installed homebrew openmotif and Mac xorg X . Then this was my ./configure > > CFLAGS='-I/usr/X11/include' LDFLAGS='-L/usr/X11/lib' ./configure --with-motif --with-x > > And snd got build without errors. > > Adding homebrew vorbis-tools, mpg123, mpg321 nade snd even happier. Fftw3 I had already, flac also. > > Misleading was, that these were completely ignored, so I ended up on X-error > > X features: > --x-includes=DIR X include files are in DIR > --x-libraries=DIR X library files are in DIR > > HTH > > -n > > >> On 9. Sep 2020, at 19.11, ludger br?mmer wrote: >> >> Hi all >> >> don?t know If I am the only OSX user here, but, being not an experienced coder, I tried to compile SND with motif on OSX several time over the last years and most of the time it failed. I got only GTK to run. So I would be happy if the solution you will find could work on OSX without having a good recommendation for a specific system myself. >> >> >> viele Gr??e / all the best >> Ludger Br?mmer >> >> -- >> Prof. Ludger Br?mmer >> Leitung | Head of Department >> Hertz-Labor | Hertz-Lab >> >> Professor f?r Komposition f?r digitale Medien >> Musikhochschule Trossingen, mh-trossingen.de >> >> /////// / |< ||| | ZKM | Zentrum f?r Kunst und Medien Karlsruhe >> /////// / |< ||| | ZKM | Center for Art and Media Karlsruhe >> /////// / |< ||| | ZKM | Centre d'Art et des M?dias Karlsruhe >> >> Lorenzstr. 19, D-76135 Karlsruhe >> Tel +49-(0)721-8100-1601, Fax +49-(0)721-8100-1699 >> E-Mail: ludger.bruemmer at zkm.de >> www.zkm.de >> >> >> >> Aktuelle Ausstellungen ? current exhibitions >> >>> Am 09.09.2020 um 17:25 schrieb Kjetil Matheussen >: >>> >>> On Wed, Sep 9, 2020 at 4:05 PM > wrote: >>>> >>>> That is interesting -- thanks for the pointer! I wonder >>>> if writing raw X code is a good idea -- people say Wayland >>>> is the future (but they've been saying that for a decade). >>>> I don't know how toolkits like gtk work with it -- that >>>> was one reason to stick with gtk for so long. >>> >>> I would say raw X (or Wayland) is a bad idea since it would mostly >>> limit Snd to run on Linux only. If you want to make your own widgets, >>> and only need a canvas to draw on, gdk, SDL, or JUCE might be good >>> alternatives (haven't tried SDL though). Or cairo? >>> _______________________________________________ >>> Cmdist mailing list >>> Cmdist at ccrma.stanford.edu >>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Fri, 11 Sep 2020 10:25:15 +0200 > From: Tito Latini > To: bil at ccrma.Stanford.EDU > Cc: cmdist at ccrma.Stanford.EDU > Subject: Re: [CM] Snd/CLM: experimental version of src and src-channel > Message-ID: <20200911082515.GA1702 at vis.roboris> > Content-Type: text/plain; charset=us-ascii > > On Thu, Sep 10, 2020 at 11:06:01AM -0700, bil at ccrma.Stanford.EDU wrote: >> Thanks! I see only a subtle difference -- do you have >> a (hopefully small) test case? (Am I right that your >> version is more consistent with the sinc_table initialization? >> It's been a long time since I looked at this code). >> I've merged your changes in, but kept the old way under >> a compile-time switch so it's easy to move back and forth. >> I'll update the ccrma versions tomorrow morning. > > Currently I have just some examples with sound files and sinusoids, to > check aliasing and amplitude. I think the resampler is correct if the > changed code passes all the tests for the original src and src-channel. > This message for the mailing list is also an informal test for some > user code. > > About the consistence with the sinc_table initialization: the weak > point of the original version is the table index with non-integer high > rates: > > x = zf * (srp->width_1 - srpx); > sinc_loc = x + srp->sinc4; > > It means: > > /* > * Memo: `width' is half length. It originally was the width > * of half sinc (the right side). > */ > L = SRC_SINC_DENSITY; > x = L * (1 - width - frac(rate)) / rate; > table_index = x + L * width + padding; > > ==> k = padding + L * (1 - frac(rate)) > table_index = L * width * (1 - 1/rate) + k; > > If the non-integer rate >1 is near 1, the first table index is low > and the interpolated sinc is windowed (the approximation depends on rate), > otherwise... > > lim L * width * (1 - 1/rate) = L * width [= main_lobe_peak] > rate -> inf > > ...the sinc is truncated with high values of rate. > > The first index in the new version is > > L * (1 - frac(rate)) + padding; > > The range is [padding; L + padding]. > > Padding is necessary with the original version. > Note: the sinc() begins at the index 0 of the table but the window > starts at index `padding'. > > The window is interpolated, but I think it is possible to remove the > interpolation for low values of `width'; however that's a minor > optimization without considerable enhancements. Kaiser window with > adjustable parameter makes the difference. > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Sep 2020 12:33:23 +0200 > From: Tito Latini > To: bil at ccrma.Stanford.EDU > Cc: cmdist at ccrma.Stanford.EDU > Subject: Re: [CM] Snd/CLM: experimental version of src and src-channel > Message-ID: <20200911103323.GA4772 at vis.roboris> > Content-Type: text/plain; charset=us-ascii > > Hey Bill, a copy-and-paste failed in svn. Attached a fix. > > > ------------------------------ > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > > > End of Cmdist Digest, Vol 148, Issue 14 > *************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From j_hearon at hotmail.com Fri Sep 11 10:46:02 2020 From: j_hearon at hotmail.com (James Hearon) Date: Fri, 11 Sep 2020 17:46:02 +0000 Subject: [CM] mix-home, etc. Message-ID: Hi, I'm getting hung up in mixes. Trying something like the manual example, below, but getting back an error that the argument is a pair, not a mix (object). Wondering we're I might be going wrong? Thank you, Jim --------------------- mix-home mix mix-home returns a list containing the mix's output sound and channel number, and the input original filename (if any), and input channel. > (define mx (mix "pistol.snd" 1000)) # > (mix-home mx) (# 0 "/home/bil/cl/pistol.snd" 0) ;; (list output-sound-index output-channel input-filename input-channel) > (set! mx (mix-float-vector (make-float-vector 100 .1) 2000)) # > (mix-home mx) (# 0 #f 0) ;; #f: no input file ------------------- mine: (begin (open-sound "oboe.snd")) (define mx (mix "pistol.snd" 1000)) >(#) (mix-home mx) ;XXX >mix-home argument 1, (#), is a pair but should be a mix ...stuck on other calls too such as (mix-maxamp mx) (mix-name->id 0) (set! (mix-amp mx) .05) but (find-mix 0 0 0) ;works -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Fri Sep 11 11:02:03 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Fri, 11 Sep 2020 11:02:03 -0700 Subject: [CM] mix-home, etc. In-Reply-To: References: Message-ID: <6460f7ff203f881a539b6abc22ee909b@ccrma.stanford.edu> That example is out-of-date -- thanks for pointing it out. The mix function returns a list of mixes, so (define mx (mix "oboe.snd")) (mix-home (car mx)) should do what you want. From chris.actondev at gmail.com Fri Sep 11 13:10:50 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Fri, 11 Sep 2020 22:10:50 +0200 Subject: [CM] Showcase: s7 REPL with Reaper (the DAW) Message-ID: Hi, Just made public this https://github.com/actonDev/s7-reaper/ It exposes Reaper's C API to S7. Quoting from the readme Features: - writing simple actions scripts - writing gui scripts with s7 & dear imgui - REPL over a socket that can leverage emacs to remotely control reaper I think people that know & use Reaper will find it useful. And, as mentioned in the readme, ideas/suggestions/help would be more than welcome. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Fri Sep 11 14:05:36 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Fri, 11 Sep 2020 14:05:36 -0700 Subject: [CM] Showcase: s7 REPL with Reaper (the DAW) In-Reply-To: References: Message-ID: Oh nice! I will definitely play with this, I love Reaper and haven't dug into the C API yet. Will you do a demo video, Christos? :-) iain On Fri, Sep 11, 2020 at 1:11 PM Christos Vagias wrote: > Hi, > > Just made public this https://github.com/actonDev/s7-reaper/ > It exposes Reaper's C API to S7. > > Quoting from the readme > Features: > - writing simple actions scripts > - writing gui scripts with s7 & dear imgui > - REPL over a socket > that can leverage emacs to remotely control reaper > > I think people that know & use Reaper will find it useful. > > And, as mentioned in the readme, ideas/suggestions/help would be more than > welcome. > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Fri Sep 11 16:30:46 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 12 Sep 2020 01:30:46 +0200 Subject: [CM] Showcase: s7 REPL with Reaper (the DAW) In-Reply-To: References: Message-ID: Nah no video this time. Maybe in the future, when I have some interesting ways of using this. By the way, next week I'll have my hands on "Notes from the Metalevel", so I wanna see if I get any interesting ideas from there. That, and combining it with literate programming (an org-mode document coupled with executable code snippets) are directions I want to explore. About Reaper's C API: see https://www.reaper.fm/sdk/reascript/reascripthelp.html#c for a (complete) taste. Oh, and I might bother you for some OSX build then in the future :) On Fri, 11 Sep 2020 at 23:05, Iain Duncan wrote: > Oh nice! I will definitely play with this, I love Reaper and haven't dug > into the C API yet. > > Will you do a demo video, Christos? :-) > > iain > > On Fri, Sep 11, 2020 at 1:11 PM Christos Vagias > wrote: > >> Hi, >> >> Just made public this https://github.com/actonDev/s7-reaper/ >> It exposes Reaper's C API to S7. >> >> Quoting from the readme >> Features: >> - writing simple actions scripts >> - writing gui scripts with s7 & dear imgui >> - REPL over a socket >> that can leverage emacs to remotely control reaper >> >> I think people that know & use Reaper will find it useful. >> >> And, as mentioned in the readme, ideas/suggestions/help would be more >> than welcome. >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Sat Sep 12 02:46:04 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Sat, 12 Sep 2020 02:46:04 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> Message-ID: I think s7_free is usable now. I also have a valgrind suppressions file for it which I could include in the s7 tarball if it seems useful. From iainduncanlists at gmail.com Sat Sep 12 09:00:19 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 12 Sep 2020 09:00:19 -0700 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> Message-ID: Nice! This will be an improvement for scheme-for-max too, where I really have no idea how many times people might create and delete the s4m object in a max patch. Thanks Bill! iain On Sat, Sep 12, 2020 at 2:46 AM wrote: > I think s7_free is usable now. I also have a valgrind > suppressions file for it which I could include in the > s7 tarball if it seems useful. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Sat Sep 12 12:26:39 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 12 Sep 2020 21:26:39 +0200 Subject: [CM] Freeing up s7 instances & memory In-Reply-To: References: <95423dd9878d0461de0fafaf71938e5f@ccrma.stanford.edu> <0341ad92f181b3977d840e4f311254ca@ccrma.stanford.edu> Message-ID: Thanks a lot Bil! That was quick. I just went on testing it and sadly the scenario I had described initially sees no improvement at all. (and yes, I'm calling s7_free instead of free heh) If it's of any help, here's another scenario where the behavior is kind of weird (it was like this even before this patch actually) for (int i = 0; i < 10; i++) { s7_scheme *sc = s7_init(); aod::s7::bind_all(sc); for (int j = 0; j < 10; j++) { // 10 times creating a ~10mb string s7_eval_c_string(sc, // "(define x ((aod.c.foreign 'new-char[]) 10000000))" // 10 mb ); } s7_eval_c_string(sc, "(gc)"); s7_eval_c_string(sc, "(gc)"); s7_free(sc); } So, 10 loops of 10 times ~10mb. After this first inner loop (10 times 10mb char*), Before the first (gc) call I notice the memory usage jump from 18mb (init) to 113mb ( + ~100mb as expected) - 1st call to (gc) has no effect - After the 2nd (gc) call, I see the memory usage dropping to 28mb Then, the s7_free has no effect at all. Then, in any subsequent loop (i=1,2...) the (gc) call has no immediate effect! The memory however doesn't increase as much in each loop, guess certain memory is being reused. Now, if I skip the (gc) calls, the memory once more tends to grow 100mb per outer loop. If I leave one (gc) call, I'm back to where in the first outer loop ~100mb are free and then in subsequent loops the memory doesn't increase as much. ::::::: Hope this isn't too confusing. What seems to happen: 2 calls are needed to the (gc) to have any effect. In my scenario where I call only once the (gc), the thing is that s7_free also calls once g_gc(sc, sc->nil); And, again, note that in my original snippet (where I only create 1 big object), s7_free seems to have no effect (the (gc) calls neither) Hope this is kind of useful. On Sat, 12 Sep 2020 at 11:46, wrote: > I think s7_free is usable now. I also have a valgrind > suppressions file for it which I could include in the > s7 tarball if it seems useful. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From squarewave at elisanet.fi Sat Sep 12 17:02:13 2020 From: squarewave at elisanet.fi (Matti Koskinen) Date: Sun, 13 Sep 2020 03:02:13 +0300 Subject: [CM] Cmdist Digest, Vol 148, Issue 14 In-Reply-To: <452FC67F-F83C-43C9-A53D-FAF8B17156CA@me.com> References: <452FC67F-F83C-43C9-A53D-FAF8B17156CA@me.com> Message-ID: <58DAF97D-02DA-4E47-B4C7-B181B2A05801@elisanet.fi> Hi Daniel, Have you mixed homebrew and macports? That?s not a good idea they say. I?ve personally used only homebrew, and I haven?t had any issues installing software I?ve needed. Openmotif needed Xquartz, setting the CFLAGS was all really needed, the libs were found automagically, but setting -L/usr/X11/lib in LDFLAGS didn?t mess anything, and it looked more correct. Yes, X11 is dying, but as I?m used to use motif on Linux, I just tried to build snd with motif on macOS, and it works nicely. Best regards -m > On 11. Sep 2020, at 14.01, DR. Daniel Hensel wrote: > > gtk in snd? > > Matti, > > On my Mac-Systems Fftw is only recognised when the port fftw-single is installed: > > sudo port install fftw-single > > One needs to specify the Architecture to get rid of the X-error: > > This works for me: > ./configure -prefix=/opt/snd-s7 CFLAGS="-arch x86_64 -I/opt/X11/include" LDFLAGS="-L/opt/X11/lib -lmx -bind_at_load" -with-gsl -with-gtk -with-s7 > > I personally cannot recommend to work with it on macOS anymore, due to increasing audio-latency and fading X11-support. On macOS Big Sur I?ll use it in a virtual Linux-machine, so I won?t have to mess with homebrew and Macports. > > All the best, > Daniel > >> Am 11.09.2020 um 12:27 schrieb cmdist-request at ccrma.stanford.edu >: >> >> Send Cmdist mailing list submissions to >> cmdist at ccrma.stanford.edu >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> or, via email, send a message with subject or body 'help' to >> cmdist-request at ccrma.stanford.edu >> >> You can reach the person managing the list at >> cmdist-owner at ccrma.stanford.edu >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Cmdist digest..." >> >> >> Today's Topics: >> >> 1. Re: gtk in snd? (Matti Koskinen) >> 2. Re: Snd/CLM: experimental version of src and src-channel >> (Tito Latini) >> 3. Re: Snd/CLM: experimental version of src and src-channel >> (Tito Latini) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 11 Sep 2020 03:13:41 +0300 >> From: Matti Koskinen >> To: ludger br?mmer >> Cc: commonmusic-Mailing-List List >> Subject: Re: [CM] gtk in snd? >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >> >> I got snd + motif working on macOS Catalina. >> >> I installed homebrew openmotif and Mac xorg X . Then this was my ./configure >> >> CFLAGS='-I/usr/X11/include' LDFLAGS='-L/usr/X11/lib' ./configure --with-motif --with-x >> >> And snd got build without errors. >> >> Adding homebrew vorbis-tools, mpg123, mpg321 nade snd even happier. Fftw3 I had already, flac also. >> >> Misleading was, that these were completely ignored, so I ended up on X-error >> >> X features: >> --x-includes=DIR X include files are in DIR >> --x-libraries=DIR X library files are in DIR >> >> HTH >> >> -n >> >> >>> On 9. Sep 2020, at 19.11, ludger br?mmer wrote: >>> >>> Hi all >>> >>> don?t know If I am the only OSX user here, but, being not an experienced coder, I tried to compile SND with motif on OSX several time over the last years and most of the time it failed. I got only GTK to run. So I would be happy if the solution you will find could work on OSX without having a good recommendation for a specific system myself. >>> >>> >>> viele Gr??e / all the best >>> Ludger Br?mmer >>> >>> -- >>> Prof. Ludger Br?mmer >>> Leitung | Head of Department >>> Hertz-Labor | Hertz-Lab >>> >>> Professor f?r Komposition f?r digitale Medien >>> Musikhochschule Trossingen, mh-trossingen.de >>> >>> /////// / |< ||| | ZKM | Zentrum f?r Kunst und Medien Karlsruhe >>> /////// / |< ||| | ZKM | Center for Art and Media Karlsruhe >>> /////// / |< ||| | ZKM | Centre d'Art et des M?dias Karlsruhe >>> >>> Lorenzstr. 19, D-76135 Karlsruhe >>> Tel +49-(0)721-8100-1601, Fax +49-(0)721-8100-1699 >>> E-Mail: ludger.bruemmer at zkm.de >>> www.zkm.de >>> >>> >>> >>> Aktuelle Ausstellungen ? current exhibitions >>> >>>> Am 09.09.2020 um 17:25 schrieb Kjetil Matheussen >: >>>> >>>> On Wed, Sep 9, 2020 at 4:05 PM > wrote: >>>>> >>>>> That is interesting -- thanks for the pointer! I wonder >>>>> if writing raw X code is a good idea -- people say Wayland >>>>> is the future (but they've been saying that for a decade). >>>>> I don't know how toolkits like gtk work with it -- that >>>>> was one reason to stick with gtk for so long. >>>> >>>> I would say raw X (or Wayland) is a bad idea since it would mostly >>>> limit Snd to run on Linux only. If you want to make your own widgets, >>>> and only need a canvas to draw on, gdk, SDL, or JUCE might be good >>>> alternatives (haven't tried SDL though). Or cairo? >>>> _______________________________________________ >>>> Cmdist mailing list >>>> Cmdist at ccrma.stanford.edu >>>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >>> >>> _______________________________________________ >>> Cmdist mailing list >>> Cmdist at ccrma.stanford.edu >>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 2 >> Date: Fri, 11 Sep 2020 10:25:15 +0200 >> From: Tito Latini >> To: bil at ccrma.Stanford.EDU >> Cc: cmdist at ccrma.Stanford.EDU >> Subject: Re: [CM] Snd/CLM: experimental version of src and src-channel >> Message-ID: <20200911082515.GA1702 at vis.roboris> >> Content-Type: text/plain; charset=us-ascii >> >> On Thu, Sep 10, 2020 at 11:06:01AM -0700, bil at ccrma.Stanford.EDU wrote: >>> Thanks! I see only a subtle difference -- do you have >>> a (hopefully small) test case? (Am I right that your >>> version is more consistent with the sinc_table initialization? >>> It's been a long time since I looked at this code). >>> I've merged your changes in, but kept the old way under >>> a compile-time switch so it's easy to move back and forth. >>> I'll update the ccrma versions tomorrow morning. >> >> Currently I have just some examples with sound files and sinusoids, to >> check aliasing and amplitude. I think the resampler is correct if the >> changed code passes all the tests for the original src and src-channel. >> This message for the mailing list is also an informal test for some >> user code. >> >> About the consistence with the sinc_table initialization: the weak >> point of the original version is the table index with non-integer high >> rates: >> >> x = zf * (srp->width_1 - srpx); >> sinc_loc = x + srp->sinc4; >> >> It means: >> >> /* >> * Memo: `width' is half length. It originally was the width >> * of half sinc (the right side). >> */ >> L = SRC_SINC_DENSITY; >> x = L * (1 - width - frac(rate)) / rate; >> table_index = x + L * width + padding; >> >> ==> k = padding + L * (1 - frac(rate)) >> table_index = L * width * (1 - 1/rate) + k; >> >> If the non-integer rate >1 is near 1, the first table index is low >> and the interpolated sinc is windowed (the approximation depends on rate), >> otherwise... >> >> lim L * width * (1 - 1/rate) = L * width [= main_lobe_peak] >> rate -> inf >> >> ...the sinc is truncated with high values of rate. >> >> The first index in the new version is >> >> L * (1 - frac(rate)) + padding; >> >> The range is [padding; L + padding]. >> >> Padding is necessary with the original version. >> Note: the sinc() begins at the index 0 of the table but the window >> starts at index `padding'. >> >> The window is interpolated, but I think it is possible to remove the >> interpolation for low values of `width'; however that's a minor >> optimization without considerable enhancements. Kaiser window with >> adjustable parameter makes the difference. >> >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 11 Sep 2020 12:33:23 +0200 >> From: Tito Latini >> To: bil at ccrma.Stanford.EDU >> Cc: cmdist at ccrma.Stanford.EDU >> Subject: Re: [CM] Snd/CLM: experimental version of src and src-channel >> Message-ID: <20200911103323.GA4772 at vis.roboris> >> Content-Type: text/plain; charset=us-ascii >> >> Hey Bill, a copy-and-paste failed in svn. Attached a fix. >> >> >> ------------------------------ >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> >> >> End of Cmdist Digest, Vol 148, Issue 14 >> *************************************** > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: From tito.01beta at gmail.com Sat Sep 12 23:54:40 2020 From: tito.01beta at gmail.com (Tito Latini) Date: Sun, 13 Sep 2020 08:54:40 +0200 Subject: [CM] Snd/CLM: experimental version of src and src-channel In-Reply-To: <2f2853d264e21852ef1f9f86a53cbc85@ccrma.stanford.edu> References: <20200910151343.GA2948@vis.roboris> <2f2853d264e21852ef1f9f86a53cbc85@ccrma.stanford.edu> Message-ID: <20200913065440.GA1344@vis.roboris> To all the persons: please don't try the patch because that change requires pre-filtering of the input, therefore it is not a complete resampler. Good Sunday. From iainduncanlists at gmail.com Sat Sep 19 10:34:22 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 19 Sep 2020 10:34:22 -0700 Subject: [CM] Help sought for a macro Message-ID: Hi colleagues, I'm trying to figure out how to build a couple of threading macros that would be very helpful in Max/MSP for Scheme for Max, but it is frankly over my head right now. Working it out will be a good exercise but I figured I would post here in case this is trivial for some macro experts in S7 and they are willing to share something I can study. I want to implement something like srfi-197, where it is called "chain". (but srfi-197 uses syntax-case and syntax-rules) so from the docs there: (chain x (a b _)) ; => (a b x) (chain (a b) (c _ d) (e f _)) ; => (let* ((x (a b)) (x (c x d))) (e f x)) (chain (a) (b _ _) (c _)) ; => (let*-values (((x1 x2) (a)) ((x) (b x1 x2))) (c x)) But what I'd really to make on top of that is a version for allows one to use this for one liners in Max without inner parens, so something like this, where the macro is ~> (x ~> a _ b ~> c _ ) becomes something equivalent of: (c (a (eval x) b)) Because Scheme for Max will take a max message and treat it as code to be wrapped in outer parens and then eval'd, this will let people do very useful things in one short max message (where say $i and $i2 come from another max message sending to it: $i1 ~> + 10 _ ~> / $i2 _ If anyone has suggestions or feels like helping that would be amazing. thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Sat Sep 19 13:12:29 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 19 Sep 2020 22:12:29 +0200 Subject: [CM] Help sought for a macro In-Reply-To: References: Message-ID: Hi Iain, Wasn't aware of the chain srfi. Interesting. Since I'm coming more from clojure I guess I'll focus a bit more on the "as->", "->" and "->>". Could try fiddling with these from Monday on and will keep you posted on the process. The "(x ~> a _ b ~> c _ )" form seems kinda too much though, adding infix notation to the mix On Sat, 19 Sep 2020 at 19:37, Iain Duncan wrote: > Hi colleagues, I'm trying to figure out how to build a couple of threading > macros that would be very helpful in Max/MSP for Scheme for Max, but it is > frankly over my head right now. Working it out will be a good exercise but > I figured I would post here in case this is trivial for some macro experts > in S7 and they are willing to share something I can study. > > I want to implement something like srfi-197, where it is called "chain". > (but srfi-197 uses syntax-case and syntax-rules) > > so from the docs there: > > (chain x (a b _)) ; => (a b x) > (chain (a b) (c _ d) (e f _)) ; => (let* ((x (a b)) (x (c x d))) (e f x)) > (chain (a) (b _ _) (c _)) ; => (let*-values (((x1 x2) (a)) ((x) (b x1 x2))) (c x)) > > > But what I'd really to make on top of that is a version for allows one to > use this for one liners in Max without inner parens, so something like > this, where the macro is ~> > > (x ~> a _ b ~> c _ ) > becomes something equivalent of: > (c (a (eval x) b)) > > Because Scheme for Max will take a max message and treat it as code to be > wrapped in outer parens and then eval'd, this will let people do very > useful things in one short max message (where say $i and $i2 come from > another max message sending to it: > > $i1 ~> + 10 _ ~> / $i2 _ > > If anyone has suggestions or feels like helping that would be amazing. > thanks! > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Sat Sep 19 13:22:52 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 19 Sep 2020 13:22:52 -0700 Subject: [CM] Help sought for a macro In-Reply-To: References: Message-ID: thanks Christos. I guess my one liner example was not clear, it's not infix notation, it's still prefix notation, just as one whitespace and token separated call. As in, the first slot in each ~> delimited s-exp is still a function call, the parens are just implied. I imagine it's not of use to anyone outside of Max, but it will be very useful in that context. To clarify what I meant, this is probably a better example: (x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3) would execute the same as (chain (eval x) (fun1 arg1 _) (fun2 _ arg2 arg3) ) which is also equivalent to (fun2 (fun1 arg1 (eval x)) arg2 arg3) so it's really just a way to write chains without having parens in there, the reason being that lists in messages with max are very easy to work with when they are all whitespace separated tokens, and allow interpolation with max's built in tools. So it allows people to make s4m "one-liners" that replace a whole wack of max objects for some use cases, and have access to s4m variables. iain On Sat, Sep 19, 2020 at 1:13 PM Christos Vagias wrote: > Hi Iain, > > Wasn't aware of the chain srfi. Interesting. > Since I'm coming more from clojure I guess I'll focus a bit more on the > "as->", "->" and "->>". > Could try fiddling with these from Monday on and will keep you posted on > the process. > > The "(x ~> a _ b ~> c _ )" form seems kinda too much though, adding infix > notation to the mix > > On Sat, 19 Sep 2020 at 19:37, Iain Duncan > wrote: > >> Hi colleagues, I'm trying to figure out how to build a couple of >> threading macros that would be very helpful in Max/MSP for Scheme for Max, >> but it is frankly over my head right now. Working it out will be a good >> exercise but I figured I would post here in case this is trivial for some >> macro experts in S7 and they are willing to share something I can study. >> >> I want to implement something like srfi-197, where it is called "chain". >> (but srfi-197 uses syntax-case and syntax-rules) >> >> so from the docs there: >> >> (chain x (a b _)) ; => (a b x) >> (chain (a b) (c _ d) (e f _)) ; => (let* ((x (a b)) (x (c x d))) (e f x)) >> (chain (a) (b _ _) (c _)) ; => (let*-values (((x1 x2) (a)) ((x) (b x1 x2))) (c x)) >> >> >> But what I'd really to make on top of that is a version for allows one to >> use this for one liners in Max without inner parens, so something like >> this, where the macro is ~> >> >> (x ~> a _ b ~> c _ ) >> becomes something equivalent of: >> (c (a (eval x) b)) >> >> Because Scheme for Max will take a max message and treat it as code to be >> wrapped in outer parens and then eval'd, this will let people do very >> useful things in one short max message (where say $i and $i2 come from >> another max message sending to it: >> >> $i1 ~> + 10 _ ~> / $i2 _ >> >> If anyone has suggestions or feels like helping that would be amazing. >> thanks! >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Sat Sep 19 13:47:08 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 19 Sep 2020 22:47:08 +0200 Subject: [CM] Help sought for a macro In-Reply-To: References: Message-ID: I kind of get it, but I think that your example should be (~> eval x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3) To produce the same thing as you said, (fun2 (fun1 arg1 (eval x)) arg2 arg3) I realise that x in your case will always be incoming string data that you want to eval it, and for the sake of "syntactic sugar" you want to skip writing eval every time. But that would be a special case that is built upon the ~>. And for the ~> I think the modification I mentioned would be needed. Also, in this example, in the "eval x" form, the "_" would be nil to start with. So the first step is to agree on the syntax :) After that, could probably dig a bit into it next week (from Monday on) and will let you know in private. On Sat, 19 Sep 2020 at 22:23, Iain Duncan wrote: > thanks Christos. I guess my one liner example was not clear, it's not > infix notation, it's still prefix notation, just as one whitespace and > token separated call. As in, the first slot in each ~> delimited s-exp is > still a function call, the parens are just implied. I imagine it's not of > use to anyone outside of Max, but it will be very useful in that context. > To clarify what I meant, this is probably a better example: > > (x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3) > would execute the same as > (chain (eval x) (fun1 arg1 _) (fun2 _ arg2 arg3) ) > which is also equivalent to > (fun2 (fun1 arg1 (eval x)) arg2 arg3) > > so it's really just a way to write chains without having parens in there, > the reason being that lists in messages with max are very easy to work with > when they are all whitespace separated tokens, and allow interpolation with > max's built in tools. So it allows people to make s4m "one-liners" that > replace a whole wack of max objects for some use cases, and have access to > s4m variables. > > iain > > > On Sat, Sep 19, 2020 at 1:13 PM Christos Vagias > wrote: > >> Hi Iain, >> >> Wasn't aware of the chain srfi. Interesting. >> Since I'm coming more from clojure I guess I'll focus a bit more on the >> "as->", "->" and "->>". >> Could try fiddling with these from Monday on and will keep you posted on >> the process. >> >> The "(x ~> a _ b ~> c _ )" form seems kinda too much though, adding infix >> notation to the mix >> >> On Sat, 19 Sep 2020 at 19:37, Iain Duncan >> wrote: >> >>> Hi colleagues, I'm trying to figure out how to build a couple of >>> threading macros that would be very helpful in Max/MSP for Scheme for Max, >>> but it is frankly over my head right now. Working it out will be a good >>> exercise but I figured I would post here in case this is trivial for some >>> macro experts in S7 and they are willing to share something I can study. >>> >>> I want to implement something like srfi-197, where it is called >>> "chain". (but srfi-197 uses syntax-case and syntax-rules) >>> >>> so from the docs there: >>> >>> (chain x (a b _)) ; => (a b x) >>> (chain (a b) (c _ d) (e f _)) ; => (let* ((x (a b)) (x (c x d))) (e f x)) >>> (chain (a) (b _ _) (c _)) ; => (let*-values (((x1 x2) (a)) ((x) (b x1 x2))) (c x)) >>> >>> >>> But what I'd really to make on top of that is a version for allows one >>> to use this for one liners in Max without inner parens, so something like >>> this, where the macro is ~> >>> >>> (x ~> a _ b ~> c _ ) >>> becomes something equivalent of: >>> (c (a (eval x) b)) >>> >>> Because Scheme for Max will take a max message and treat it as code to >>> be wrapped in outer parens and then eval'd, this will let people do very >>> useful things in one short max message (where say $i and $i2 come from >>> another max message sending to it: >>> >>> $i1 ~> + 10 _ ~> / $i2 _ >>> >>> If anyone has suggestions or feels like helping that would be amazing. >>> thanks! >>> _______________________________________________ >>> Cmdist mailing list >>> Cmdist at ccrma.stanford.edu >>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Sat Sep 19 14:06:20 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 19 Sep 2020 14:06:20 -0700 Subject: [CM] Help sought for a macro In-Reply-To: References: Message-ID: Oops, you're right I meant to start the example with the ~> macro. And I'm not really attached to whether or not one has to write "eval" or not, or even start with that clause. That thing could be whatever: variable, symbol, number, string. It could just as usefully be (where $i1 is integer from an incoming max message) So maybe this is a better example (albeit a bit contrived), where the message is triggered by a message with two values, that become $i1 and $i2 (max does this for us) ~> random $i1 ~> + $i2 _ ~> * -1 _ which could also be, if I'm thinking straight, written as: ~> eval $i1 ~> random _ ~> + $i2 _ ~> * -1 _ Does that make more sense? I had originally been thinking of the clojure syntax for thread first and thread last, but then upon seeing the chain sfri, I thought the use of _ was going to be more generally readable, and more useful in cases where one might be interpolating to anywhere in arg positions. Just seems like an elegant version of Clojure's thread-as macro? The issue in max is that one has to do something different when you have the parens in there, requiring more message objects in the patch. (you have to make it a symbol, and then pipe it to s4m as eval-string {symbol}. It's certainly not a big inconvenience, but it would be nice to support both options. thanks for looking at this! On Sat, Sep 19, 2020 at 1:47 PM Christos Vagias wrote: > I kind of get it, but I think that your example should be > (~> eval x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3) > > To produce the same thing as you said, > (fun2 (fun1 arg1 (eval x)) arg2 arg3) > > I realise that x in your case will always be incoming string data that you > want to eval it, > and for the sake of "syntactic sugar" you want to skip writing eval every > time. > > But that would be a special case that is built upon the ~>. And for the ~> > I think > the modification I mentioned would be needed. Also, in this example, in > the "eval x" form, > the "_" would be nil to start with. > > So the first step is to agree on the syntax :) > After that, could probably dig a bit into it next week (from Monday on) > and will let you know > in private. > > > On Sat, 19 Sep 2020 at 22:23, Iain Duncan > wrote: > >> thanks Christos. I guess my one liner example was not clear, it's not >> infix notation, it's still prefix notation, just as one whitespace and >> token separated call. As in, the first slot in each ~> delimited s-exp is >> still a function call, the parens are just implied. I imagine it's not of >> use to anyone outside of Max, but it will be very useful in that context. >> To clarify what I meant, this is probably a better example: >> >> (x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3) >> would execute the same as >> (chain (eval x) (fun1 arg1 _) (fun2 _ arg2 arg3) ) >> which is also equivalent to >> (fun2 (fun1 arg1 (eval x)) arg2 arg3) >> >> so it's really just a way to write chains without having parens in there, >> the reason being that lists in messages with max are very easy to work with >> when they are all whitespace separated tokens, and allow interpolation with >> max's built in tools. So it allows people to make s4m "one-liners" that >> replace a whole wack of max objects for some use cases, and have access to >> s4m variables. >> >> iain >> >> >> On Sat, Sep 19, 2020 at 1:13 PM Christos Vagias >> wrote: >> >>> Hi Iain, >>> >>> Wasn't aware of the chain srfi. Interesting. >>> Since I'm coming more from clojure I guess I'll focus a bit more on the >>> "as->", "->" and "->>". >>> Could try fiddling with these from Monday on and will keep you posted on >>> the process. >>> >>> The "(x ~> a _ b ~> c _ )" form seems kinda too much though, adding >>> infix notation to the mix >>> >>> On Sat, 19 Sep 2020 at 19:37, Iain Duncan >>> wrote: >>> >>>> Hi colleagues, I'm trying to figure out how to build a couple of >>>> threading macros that would be very helpful in Max/MSP for Scheme for Max, >>>> but it is frankly over my head right now. Working it out will be a good >>>> exercise but I figured I would post here in case this is trivial for some >>>> macro experts in S7 and they are willing to share something I can study. >>>> >>>> I want to implement something like srfi-197, where it is called >>>> "chain". (but srfi-197 uses syntax-case and syntax-rules) >>>> >>>> so from the docs there: >>>> >>>> (chain x (a b _)) ; => (a b x) >>>> (chain (a b) (c _ d) (e f _)) ; => (let* ((x (a b)) (x (c x d))) (e f x)) >>>> (chain (a) (b _ _) (c _)) ; => (let*-values (((x1 x2) (a)) ((x) (b x1 x2))) (c x)) >>>> >>>> >>>> But what I'd really to make on top of that is a version for allows one >>>> to use this for one liners in Max without inner parens, so something like >>>> this, where the macro is ~> >>>> >>>> (x ~> a _ b ~> c _ ) >>>> becomes something equivalent of: >>>> (c (a (eval x) b)) >>>> >>>> Because Scheme for Max will take a max message and treat it as code to >>>> be wrapped in outer parens and then eval'd, this will let people do very >>>> useful things in one short max message (where say $i and $i2 come from >>>> another max message sending to it: >>>> >>>> $i1 ~> + 10 _ ~> / $i2 _ >>>> >>>> If anyone has suggestions or feels like helping that would be amazing. >>>> thanks! >>>> _______________________________________________ >>>> Cmdist mailing list >>>> Cmdist at ccrma.stanford.edu >>>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Sat Sep 19 14:07:23 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 19 Sep 2020 14:07:23 -0700 Subject: [CM] Help sought for a macro In-Reply-To: References: Message-ID: As far as the regular full syntax threading version goes, I lean towards the chain syntax as being a nice general solution that is more readable as the reader doesn't have to imagine inserting the arg into the subsequent sexps, the _ shows you visually what's going on right away. iain On Sat, Sep 19, 2020 at 2:06 PM Iain Duncan wrote: > Oops, you're right I meant to start the example with the ~> macro. And I'm > not really attached to whether or not one has to write "eval" or not, or > even start with that clause. That thing could be whatever: variable, > symbol, number, string. It could just as usefully be (where $i1 is integer > from an incoming max message) > > So maybe this is a better example (albeit a bit contrived), where the > message is triggered by a message with two values, that become $i1 and $i2 > (max does this for us) > > ~> random $i1 ~> + $i2 _ ~> * -1 _ > which could also be, if I'm thinking straight, written as: > ~> eval $i1 ~> random _ ~> + $i2 _ ~> * -1 _ > > Does that make more sense? I had originally been thinking of the clojure > syntax for thread first and thread last, but then upon seeing the chain > sfri, I thought the use of _ was going to be more generally readable, and > more useful in cases where one might be interpolating to anywhere in arg > positions. Just seems like an elegant version of Clojure's thread-as macro? > The issue in max is that one has to do something different when you have > the parens in there, requiring more message objects in the patch. (you have > to make it a symbol, and then pipe it to s4m as eval-string {symbol}. It's > certainly not a big inconvenience, but it would be nice to support both > options. > > thanks for looking at this! > > On Sat, Sep 19, 2020 at 1:47 PM Christos Vagias > wrote: > >> I kind of get it, but I think that your example should be >> (~> eval x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3) >> >> To produce the same thing as you said, >> (fun2 (fun1 arg1 (eval x)) arg2 arg3) >> >> I realise that x in your case will always be incoming string data that >> you want to eval it, >> and for the sake of "syntactic sugar" you want to skip writing eval >> every time. >> >> But that would be a special case that is built upon the ~>. And for the >> ~> I think >> the modification I mentioned would be needed. Also, in this example, in >> the "eval x" form, >> the "_" would be nil to start with. >> >> So the first step is to agree on the syntax :) >> After that, could probably dig a bit into it next week (from Monday on) >> and will let you know >> in private. >> >> >> On Sat, 19 Sep 2020 at 22:23, Iain Duncan >> wrote: >> >>> thanks Christos. I guess my one liner example was not clear, it's not >>> infix notation, it's still prefix notation, just as one whitespace and >>> token separated call. As in, the first slot in each ~> delimited s-exp is >>> still a function call, the parens are just implied. I imagine it's not of >>> use to anyone outside of Max, but it will be very useful in that context. >>> To clarify what I meant, this is probably a better example: >>> >>> (x ~> fun1 arg1 _ ~> fun2 _ arg2 arg3) >>> would execute the same as >>> (chain (eval x) (fun1 arg1 _) (fun2 _ arg2 arg3) ) >>> which is also equivalent to >>> (fun2 (fun1 arg1 (eval x)) arg2 arg3) >>> >>> so it's really just a way to write chains without having parens in >>> there, the reason being that lists in messages with max are very easy to >>> work with when they are all whitespace separated tokens, and allow >>> interpolation with max's built in tools. So it allows people to make s4m >>> "one-liners" that replace a whole wack of max objects for some use cases, >>> and have access to s4m variables. >>> >>> iain >>> >>> >>> On Sat, Sep 19, 2020 at 1:13 PM Christos Vagias < >>> chris.actondev at gmail.com> wrote: >>> >>>> Hi Iain, >>>> >>>> Wasn't aware of the chain srfi. Interesting. >>>> Since I'm coming more from clojure I guess I'll focus a bit more on the >>>> "as->", "->" and "->>". >>>> Could try fiddling with these from Monday on and will keep you posted >>>> on the process. >>>> >>>> The "(x ~> a _ b ~> c _ )" form seems kinda too much though, adding >>>> infix notation to the mix >>>> >>>> On Sat, 19 Sep 2020 at 19:37, Iain Duncan >>>> wrote: >>>> >>>>> Hi colleagues, I'm trying to figure out how to build a couple of >>>>> threading macros that would be very helpful in Max/MSP for Scheme for Max, >>>>> but it is frankly over my head right now. Working it out will be a good >>>>> exercise but I figured I would post here in case this is trivial for some >>>>> macro experts in S7 and they are willing to share something I can study. >>>>> >>>>> I want to implement something like srfi-197, where it is called >>>>> "chain". (but srfi-197 uses syntax-case and syntax-rules) >>>>> >>>>> so from the docs there: >>>>> >>>>> (chain x (a b _)) ; => (a b x) >>>>> (chain (a b) (c _ d) (e f _)) ; => (let* ((x (a b)) (x (c x d))) (e f x)) >>>>> (chain (a) (b _ _) (c _)) ; => (let*-values (((x1 x2) (a)) ((x) (b x1 x2))) (c x)) >>>>> >>>>> >>>>> But what I'd really to make on top of that is a version for allows one >>>>> to use this for one liners in Max without inner parens, so something like >>>>> this, where the macro is ~> >>>>> >>>>> (x ~> a _ b ~> c _ ) >>>>> becomes something equivalent of: >>>>> (c (a (eval x) b)) >>>>> >>>>> Because Scheme for Max will take a max message and treat it as code to >>>>> be wrapped in outer parens and then eval'd, this will let people do very >>>>> useful things in one short max message (where say $i and $i2 come from >>>>> another max message sending to it: >>>>> >>>>> $i1 ~> + 10 _ ~> / $i2 _ >>>>> >>>>> If anyone has suggestions or feels like helping that would be amazing. >>>>> thanks! >>>>> _______________________________________________ >>>>> Cmdist mailing list >>>>> Cmdist at ccrma.stanford.edu >>>>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Thu Sep 24 18:34:43 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 24 Sep 2020 18:34:43 -0700 Subject: [CM] Question about threading and s7 Message-ID: Hi folks, I'm hoping someone can help me out with a question around S7. In Max/MSP, when setup for live use there are (generally) two threads of operation, with the high-priority/dsp thread able to interrupt the low/GUI. If one doesn't do anything special, this means a max external (such as my Scheme-for-Max) could be receiving messages in both: low for things originating from a GUI action, high from metronomes or midi input. I assume that I should not expect all to be ok if I have one instance of an s7 interpreter, which could be accessed from either thread, and it could get interrupted part way through an eval operation to run another eval in another thread that may access the same data. IE there's no magical thread protection baked into S7 that I don't know about.... I'm wrestling with how to deal with this correctly. One option is to allow users to designate an s4m instance as always-high or always-low, basically saying if you need to mix low and high priority you should treat it like an actor model and have two interpreters that message each other and share data through some non-scheme shared data structure (like max buffers or tables). This might be ok because there is a way for me to insure incoming max messages from any thread are either promoted or demoted. I suppose another option is to get into critical sections, but I can't see how that make sense if we don't want low priority actions to have the chance of locking out high ones. Strangely, I have not had any issues yet. But I presume that just means I've been lucky. Cycling 74 does not (anymore) allow the javascript object to work in both threads, and I'm thinking it must have been around thread stability issues. Any thoughts most welcome! iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Thu Sep 24 18:41:28 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 24 Sep 2020 18:41:28 -0700 Subject: [CM] Question about threading and s7 In-Reply-To: References: Message-ID: Another option I'm thinking of is giving the users a way to expressly send messages to one or the other thread within the object (ie by requesting promote or defer) and then letting them protect the data sensibly themselves. I'm not sure how this is normally done in Scheme though. iain On Thu, Sep 24, 2020 at 6:34 PM Iain Duncan wrote: > Hi folks, I'm hoping someone can help me out with a question around S7. > > In Max/MSP, when setup for live use there are (generally) two threads of > operation, with the high-priority/dsp thread able to interrupt the low/GUI. > If one doesn't do anything special, this means a max external (such as my > Scheme-for-Max) could be receiving messages in both: low for things > originating from a GUI action, high from metronomes or midi input. I > assume that I should not expect all to be ok if I have one instance of an > s7 interpreter, which could be accessed from either thread, and it could > get interrupted part way through an eval operation to run another eval in > another thread that may access the same data. IE there's no magical thread > protection baked into S7 that I don't know about.... > > I'm wrestling with how to deal with this correctly. One option is to allow > users to designate an s4m instance as always-high or always-low, basically > saying if you need to mix low and high priority you should treat it like an > actor model and have two interpreters that message each other and share > data through some non-scheme shared data structure (like max buffers or > tables). This might be ok because there is a way for me to insure incoming > max messages from any thread are either promoted or demoted. > > I suppose another option is to get into critical sections, but I can't see > how that make sense if we don't want low priority actions to have the > chance of locking out high ones. > > Strangely, I have not had any issues yet. But I presume that just means > I've been lucky. Cycling 74 does not (anymore) allow the javascript object > to work in both threads, and I'm thinking it must have been around thread > stability issues. > > Any thoughts most welcome! > iain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Fri Sep 25 03:51:59 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Fri, 25 Sep 2020 12:51:59 +0200 Subject: [CM] Question about threading and s7 In-Reply-To: References: Message-ID: Hi Iain, Interesting problem and I'd be interested to see any input from others. I had the same problem in my VST3 scenario: the gui and the dsp run on separate threads! How I tackled this was with 2 separate s7 instances and they exchange messages. The messages are stored in the c++ application instance in an std::queue The dsp instance has the following c function bound to emit messages // the emit accepts a list with symbols,numbers etc. // the car could be your message type and then the data would follow s7_pointer s7vst::dsp_emit(s7_scheme* sc, s7_pointer args) { // the s7 instance holds in *app* the pointer of the relevant application object s7vst* that = (s7vst*) s7_c_pointer(s7_name_to_value(sc, "*app*")); s7_pointer msg = s7_car(args); std::string msg_str = s7_format(sc, s7_list(sc, 3, s7_f(sc), s7_make_string(sc, "~A\n"), msg )); std::unique_lock lock(that->dsp_msg_mutex); that->dsp_messages.push(msg_str); return s7_nil(sc); } And then, the gui instance has a "recv" function and acts upon any received messages s7_pointer s7vst::gui_recv(s7_scheme* sc, s7_pointer args) { s7vst* that = (s7vst*) s7_c_pointer(s7_name_to_value(sc, "*app*")); while (!that->dsp_msg_mutex.try_lock()) { cerr << "Gui recv: could not lock!"; std::this_thread::sleep_for(std::chrono::milliseconds(10)); } if (that->dsp_messages.empty()) { that->dsp_msg_mutex.unlock(); return s7_nil(sc); } s7_pointer msg_vector = s7_make_vector(sc, that->dsp_messages.size()); size_t pos = 0; while (!that->dsp_messages.empty()) { std::string msg = that->dsp_messages.front(); that->dsp_messages.pop(); s7_pointer port = s7_open_input_string(sc, msg.c_str()); s7_pointer obj = s7_read(sc, port); s7_close_input_port(sc, port); s7_vector_set(sc, msg_vector, pos, obj); pos++; } that->dsp_msg_mutex.unlock(); return msg_vector; } At least that's a quick & dirty way that I got it working. Sorry for the long snippets. Hope it's of help On Fri, 25 Sep 2020 at 03:41, Iain Duncan wrote: > Another option I'm thinking of is giving the users a way to expressly send > messages to one or the other thread within the object (ie by requesting > promote or defer) and then letting them protect the data sensibly > themselves. I'm not sure how this is normally done in Scheme though. > > iain > > On Thu, Sep 24, 2020 at 6:34 PM Iain Duncan > wrote: > >> Hi folks, I'm hoping someone can help me out with a question around S7. >> >> In Max/MSP, when setup for live use there are (generally) two threads of >> operation, with the high-priority/dsp thread able to interrupt the low/GUI. >> If one doesn't do anything special, this means a max external (such as my >> Scheme-for-Max) could be receiving messages in both: low for things >> originating from a GUI action, high from metronomes or midi input. I >> assume that I should not expect all to be ok if I have one instance of an >> s7 interpreter, which could be accessed from either thread, and it could >> get interrupted part way through an eval operation to run another eval in >> another thread that may access the same data. IE there's no magical thread >> protection baked into S7 that I don't know about.... >> >> I'm wrestling with how to deal with this correctly. One option is to >> allow users to designate an s4m instance as always-high or always-low, >> basically saying if you need to mix low and high priority you should treat >> it like an actor model and have two interpreters that message each other >> and share data through some non-scheme shared data structure (like max >> buffers or tables). This might be ok because there is a way for me to >> insure incoming max messages from any thread are either promoted or >> demoted. >> >> I suppose another option is to get into critical sections, but I can't >> see how that make sense if we don't want low priority actions to have the >> chance of locking out high ones. >> >> Strangely, I have not had any issues yet. But I presume that just means >> I've been lucky. Cycling 74 does not (anymore) allow the javascript object >> to work in both threads, and I'm thinking it must have been around thread >> stability issues. >> >> Any thoughts most welcome! >> iain >> > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Fri Sep 25 08:18:08 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Fri, 25 Sep 2020 08:18:08 -0700 Subject: [CM] Question about threading and s7 In-Reply-To: References: Message-ID: Thanks Christos, that is what I'm leaning to as well right now. I did some more work yesterday, and figured out that it is not hard for the Max object to check the thread it's running in and do a promotion or deferral, so I'm almost at the point where I can allow the user to mark and instance as always-high or always-low. That seems like the "safe" way, and then I may also be able to let the user run with scissors if they want to allow ops in any thread and manage their shared memory manually by wrapping Max's critical_region functions (cross-platform mutexes as far as I can tell). I'd love to hear any other stories from the trenches on how people have handled this though! On Fri, Sep 25, 2020 at 3:52 AM Christos Vagias wrote: > Hi Iain, > > Interesting problem and I'd be interested to see any input from others. > I had the same problem in my VST3 scenario: the gui and the dsp run on > separate threads! > > How I tackled this was with 2 separate s7 instances and they exchange > messages. > The messages are stored in the c++ application instance in an > std::queue > > The dsp instance has the following c function bound to emit messages > > // the emit accepts a list with symbols,numbers etc. > // the car could be your message type and then the data would follow > s7_pointer s7vst::dsp_emit(s7_scheme* sc, s7_pointer args) { > // the s7 instance holds in *app* the pointer of the relevant > application object > s7vst* that = (s7vst*) s7_c_pointer(s7_name_to_value(sc, "*app*")); > > s7_pointer msg = s7_car(args); > std::string msg_str = s7_format(sc, s7_list(sc, 3, > s7_f(sc), > s7_make_string(sc, "~A\n"), > msg > )); > std::unique_lock lock(that->dsp_msg_mutex); > that->dsp_messages.push(msg_str); > return s7_nil(sc); > } > > > And then, the gui instance has a "recv" function and acts upon any > received messages > > s7_pointer s7vst::gui_recv(s7_scheme* sc, s7_pointer args) { > s7vst* that = (s7vst*) s7_c_pointer(s7_name_to_value(sc, "*app*")); > while (!that->dsp_msg_mutex.try_lock()) { > cerr << "Gui recv: could not lock!"; > std::this_thread::sleep_for(std::chrono::milliseconds(10)); > } > > if (that->dsp_messages.empty()) { > that->dsp_msg_mutex.unlock(); > return s7_nil(sc); > } > s7_pointer msg_vector = s7_make_vector(sc, that->dsp_messages.size()); > size_t pos = 0; > while (!that->dsp_messages.empty()) { > std::string msg = that->dsp_messages.front(); > that->dsp_messages.pop(); > s7_pointer port = s7_open_input_string(sc, msg.c_str()); > s7_pointer obj = s7_read(sc, port); > s7_close_input_port(sc, port); > s7_vector_set(sc, msg_vector, pos, obj); > pos++; > } > > that->dsp_msg_mutex.unlock(); > > return msg_vector; > } > > At least that's a quick & dirty way that I got it working. > Sorry for the long snippets. > > Hope it's of help > > > On Fri, 25 Sep 2020 at 03:41, Iain Duncan > wrote: > >> Another option I'm thinking of is giving the users a way to expressly >> send messages to one or the other thread within the object (ie by >> requesting promote or defer) and then letting them protect the data >> sensibly themselves. I'm not sure how this is normally done in Scheme >> though. >> >> iain >> >> On Thu, Sep 24, 2020 at 6:34 PM Iain Duncan >> wrote: >> >>> Hi folks, I'm hoping someone can help me out with a question around S7. >>> >>> In Max/MSP, when setup for live use there are (generally) two threads of >>> operation, with the high-priority/dsp thread able to interrupt the low/GUI. >>> If one doesn't do anything special, this means a max external (such as my >>> Scheme-for-Max) could be receiving messages in both: low for things >>> originating from a GUI action, high from metronomes or midi input. I >>> assume that I should not expect all to be ok if I have one instance of an >>> s7 interpreter, which could be accessed from either thread, and it could >>> get interrupted part way through an eval operation to run another eval in >>> another thread that may access the same data. IE there's no magical thread >>> protection baked into S7 that I don't know about.... >>> >>> I'm wrestling with how to deal with this correctly. One option is to >>> allow users to designate an s4m instance as always-high or always-low, >>> basically saying if you need to mix low and high priority you should treat >>> it like an actor model and have two interpreters that message each other >>> and share data through some non-scheme shared data structure (like max >>> buffers or tables). This might be ok because there is a way for me to >>> insure incoming max messages from any thread are either promoted or >>> demoted. >>> >>> I suppose another option is to get into critical sections, but I can't >>> see how that make sense if we don't want low priority actions to have the >>> chance of locking out high ones. >>> >>> Strangely, I have not had any issues yet. But I presume that just means >>> I've been lucky. Cycling 74 does not (anymore) allow the javascript object >>> to work in both threads, and I'm thinking it must have been around thread >>> stability issues. >>> >>> Any thoughts most welcome! >>> iain >>> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> https://cm-mail.stanford.edu/mailman/listinfo/cmdist >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Fri Sep 25 17:23:56 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 26 Sep 2020 02:23:56 +0200 Subject: [CM] s7-playground (interactive tutorial) update Message-ID: Hi all, Had some progress on the interactive s7 tutorial I was planning: https://actondev.github.io/s7-playground/ The website is created with emacs & org-mode from the following file https://github.com/actonDev/s7-playground/blob/69515ec/index.org Now that the skeleton is done, it's about the content! (apologies to Bil for the shameless copy-paste text, no imagination at the moment) Contributions and ideas are more than welcome. An idea/request for Bil: I think it would be good to move this into an official organization in github (like the existing ccrma https://github.com/ccrma or a new one like https://github.com/s7-scheme, s7 is reserved). And maybe.. put the official s7 repo there as well? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdouglass at carnegierobotics.com Fri Sep 25 18:57:08 2020 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Sat, 26 Sep 2020 01:57:08 +0000 Subject: [CM] s7-playground (interactive tutorial) update In-Reply-To: References: Message-ID: <1e29b7af10e44bec8aa886711b1fecc3@carnegierobotics.com> I agree wholeheartedly about moving the repo to an organization. I'll even keep it synchronized, it just feels weird on my personal accoung On 2020-09-25 20:25:34-04:00 cmdist-bounces at ccrma.Stanford.EDU wrote: Hi all, Had some progress on the interactive s7 tutorial I was planning: https://actondev.github.io/s7-playground/ The website is created with emacs & org-mode from the following file https://github.com/actonDev/s7-playground/blob/69515ec/index.org Now that the skeleton is done, it's about the content! (apologies to Bil for the shameless copy-paste text, no imagination at the moment) Contributions and ideas are more than welcome. An idea/request for Bil: I think it would be good to move this into an official organization in github (like the existing ccrma https://github.com/ccrma or a new one like https://github.com/s7-scheme, s7 is reserved). And maybe.. put the official s7 repo there as well? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Fri Sep 25 19:07:23 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Fri, 25 Sep 2020 19:07:23 -0700 Subject: [CM] s7-playground (interactive tutorial) update In-Reply-To: <1e29b7af10e44bec8aa886711b1fecc3@carnegierobotics.com> References: <1e29b7af10e44bec8aa886711b1fecc3@carnegierobotics.com> Message-ID: +1 from me too! (though I realize this is easy to say when it involves no work on my part...) On Fri, Sep 25, 2020 at 6:57 PM Woody Douglass < wdouglass at carnegierobotics.com> wrote: > I agree wholeheartedly about moving the repo to an organization. I'll even > keep it synchronized, it just feels weird on my personal accoung > > > > On 2020-09-25 20:25:34-04:00 cmdist-bounces at ccrma.Stanford.EDU wrote: > > Hi all, > Had some progress on the interactive s7 tutorial I was > planning: https://actondev.github.io/s7-playground/ > > The website is created with emacs & org-mode from the following file > https://github.com/actonDev/s7-playground/blob/69515ec/index.org > > Now that the skeleton is done, it's about the content! > (apologies to Bil for the shameless copy-paste text, no imagination at the > moment) > > Contributions and ideas are more than welcome. > > An idea/request for Bil: I think it would be good to move this into an > official organization in github (like the existing ccrma > https://github.com/ccrma or a new one like https://github.com/s7-scheme, > s7 is reserved). And maybe.. put the official s7 repo there as well? :) > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Sat Sep 26 07:22:44 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Sat, 26 Sep 2020 07:22:44 -0700 Subject: [CM] s7-playground (interactive tutorial) update In-Reply-To: References: Message-ID: <86ff225e2c44627931261ab3749544ea@ccrma.stanford.edu> > apologies to Bil for the shameless copy-paste text no problem -- let me know of any mistakes -- it's hard to keep documentation up-to-date. On the github stuff -- I read somewhere (hacker news probably) that this is a "generational problem" -- old-timers don't see any benefit in "project management tools" whatever that means, and young folks can't imagine life without them. I don't even have a smartphone. From iainduncanlists at gmail.com Sat Sep 26 11:03:33 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 26 Sep 2020 11:03:33 -0700 Subject: [CM] s7-playground (interactive tutorial) update In-Reply-To: <86ff225e2c44627931261ab3749544ea@ccrma.stanford.edu> References: <86ff225e2c44627931261ab3749544ea@ccrma.stanford.edu> Message-ID: > > > > On the github stuff -- I read somewhere (hacker news probably) > that this is a "generational problem" -- old-timers don't > see any benefit in "project management tools" whatever that > means, and young folks can't imagine life without them. > I don't even have a smartphone. > I think I read the same thread. Was that on the emacs direction thread? :-) I think one thing that is a really big advantage of github presence though, is visibility. Sourceforge has sadly languished and is now a nightmare of advertising, and awful web design and navigation, whereas on github it is very easy to quickly take stock of how much is going on and by whom in an open source project. The reason I personally think this is important is that there is *more* s7 activity than one would be led to believe by a glance at sourceforge. For my purposes, github is great because I do want to attract users to Scheme For Max, in the hope of eventually finding more contributors. Github makes it very easy for potential users to watch, fork, see the activity by ticket, etc, all with no advertising. I don't need the tooling, it's just me so far, but I know that to attract other devs, they will want to have access to this, and it makes it smooth to work with them in a gradual manner. Of course I realize this is moot if one is not concerned about attracting users, and that is of course up to you. But I would humbly put forth that this is why it's attractive to those of us using S7 in contexts where we want to attract uptake and build a bit of a community :-) iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdouglass at carnegierobotics.com Tue Sep 29 04:21:48 2020 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Tue, 29 Sep 2020 11:21:48 +0000 Subject: [CM] s7-playground (interactive tutorial) update In-Reply-To: References: <86ff225e2c44627931261ab3749544ea@ccrma.stanford.edu>, Message-ID: <3d36c9050b214cc08ec116fb9d62186a@carnegierobotics.com> Really all it'll take is for somebody to create a github organization and allow me to create repositories, and transferring ownership of the s7 repo will be pretty straightforward. On 2020-09-26 14:05:02-04:00 cmdist-bounces at ccrma.Stanford.EDU wrote: On the github stuff -- I read somewhere (hacker news probably) that this is a "generational problem" -- old-timers don't see any benefit in "project management tools" whatever that means, and young folks can't imagine life without them. I don't even have a smartphone. I think I read the same thread. Was that on the emacs direction thread? :-) I think one thing that is a really big advantage of github presence though, is visibility. Sourceforge has sadly languished and is now a nightmare of advertising, and awful web design and navigation, whereas on github it is very easy to quickly take stock of how much is going on and by whom in an open source project. The reason I personally think this is important is that there is *more* s7 activity than one would be led to believe by a glance at sourceforge. For my purposes, github is great because I do want to attract users to Scheme For Max, in the hope of eventually finding more contributors. Github makes it very easy for potential users to watch, fork, see the activity by ticket, etc, all with no advertising. I don't need the tooling, it's just me so far, but I know that to attract other devs, they will want to have access to this, and it makes it smooth to work with them in a gradual manner. Of course I realize this is moot if one is not concerned about attracting users, and that is of course up to you. But I would humbly put forth that this is why it's attractive to those of us using S7 in contexts where we want to attract uptake and build a bit of a community :-) iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From lb at zkm.de Tue Sep 29 14:54:40 2020 From: lb at zkm.de (=?utf-8?Q?ludger_br=C3=BCmmer?=) Date: Tue, 29 Sep 2020 23:54:40 +0200 Subject: [CM] with-sound keywords from grace Message-ID: <3574F6A8-728D-4BE9-AAA1-76EA175E7963@zkm.de> Hi everyone I ran into an inconsistency regarding the keywords for with-sound in clm and Grace. The output of both examples should have the same result, but unfortunately the :scaled-to is ignored, somehow the :statistics #t as well. I guess it is because :scaled-to is a macro and not a variable. Furthermore the :data-format has to be articulated in a different way, what is in clm :data-format mus-b24int is in Grace :data-format 8. Does anyone have an idea what to do, especially the not working :scaled-to function is causing a lot of extra work. (with-sound ( :output ?test.aiff? :statistics #t :data-format mus-b24int :header-type mus-aiff :scaled-to .9 ) (fm-violin 0 10 440 .1 :fm-index 2.0)) (define (test-violin a b c d e) (process repeat 1 do (fm-violin a b c d e) (wait 1) )) (sprout (test-violin 0 10 440 .1 2.0) "test2.aiff? :statistics #t ;;;is somehow ignored :data-format 8 ;;; in Grace it is 8 and in CLM mus-b24int :header-type mus-aiff :scaled-to .9 ;;; is completely ignored ) viele Gr??e / all the best Ludger Br?mmer -- Prof. Ludger Br?mmer Leitung | Head of Department Hertz-Labor | Hertz-Lab Professor f?r Komposition f?r digitale Medien Musikhochschule Trossingen, mh-trossingen.de /////// / |< ||| | ZKM | Zentrum f?r Kunst und Medien Karlsruhe /////// / |< ||| | ZKM | Center for Art and Media Karlsruhe /////// / |< ||| | ZKM | Centre d'Art et des M?dias Karlsruhe Lorenzstr. 19, D-76135 Karlsruhe Tel +49-(0)721-8100-1601, Fax +49-(0)721-8100-1699 E-Mail: ludger.bruemmer at zkm.de www.zkm.de Aktuelle Ausstellungen ? current exhibitions -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zkm-cz.jpg Type: image/jpeg Size: 41457 bytes Desc: not available URL: From bil at ccrma.Stanford.EDU Wed Sep 30 02:53:29 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 30 Sep 2020 02:53:29 -0700 Subject: [CM] s7 git repository Message-ID: <25cc6e32f9d17e21712fda57901860dc@ccrma.stanford.edu> With help from Fernando, there is now a git repository for s7: git at cm-gitlab.stanford.edu:bil/s7.git https://cm-gitlab.stanford.edu/bil/s7.git From k.s.matheussen at gmail.com Wed Sep 30 03:00:42 2020 From: k.s.matheussen at gmail.com (Kjetil Matheussen) Date: Wed, 30 Sep 2020 12:00:42 +0200 Subject: [CM] s7 git repository In-Reply-To: <25cc6e32f9d17e21712fda57901860dc@ccrma.stanford.edu> References: <25cc6e32f9d17e21712fda57901860dc@ccrma.stanford.edu> Message-ID: Great! Here's a power git tip: git grep (much faster than grep) On Wed, Sep 30, 2020 at 11:56 AM wrote: > > With help from Fernando, there is now a git repository > for s7: > > git at cm-gitlab.stanford.edu:bil/s7.git > https://cm-gitlab.stanford.edu/bil/s7.git > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist From chris.actondev at gmail.com Wed Sep 30 03:33:22 2020 From: chris.actondev at gmail.com (Christos Vagias) Date: Wed, 30 Sep 2020 12:33:22 +0200 Subject: [CM] s7 git repository In-Reply-To: <25cc6e32f9d17e21712fda57901860dc@ccrma.stanford.edu> References: <25cc6e32f9d17e21712fda57901860dc@ccrma.stanford.edu> Message-ID: Nice! One thing though: I noticed 3 commits. I think it'd be good to preserve the commit history. There is the "git-svn" tool to convert an existing svn repo to git. My output of "git log --reverse" of the snd svn repo cloned with git-svn. (the output is the same in woody's mirror) commit e88041f23616418181b094a154d6f07e4e1d2860 Author: schottstaedt Date: Mon Oct 9 14:32:43 2017 +0000 init dirs git-svn-id: https://svn.code.sf.net/p/snd/svn1 at 1 b278ec2f-9027-4a79-a958-f306da2c2c68 I got the repo with "git svn clone https://svn.code.sf.net/p/snd/svn1/" (which took a looong time) Don't know if you can "init" the git repo with your local svn repo. Here's the complete documentation https://git-scm.com/docs/git-svn Alternatively, (if woody's repo is up to date) you could clone that, rename the "upstream" branch to "master" and push to gitlab ..Well unless the "clean state" is on purpose On Wed, 30 Sep 2020 at 11:53, wrote: > With help from Fernando, there is now a git repository > for s7: > > git at cm-gitlab.stanford.edu:bil/s7.git > https://cm-gitlab.stanford.edu/bil/s7.git > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Wed Sep 30 06:03:57 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 30 Sep 2020 06:03:57 -0700 Subject: [CM] s7 git repository In-Reply-To: References: <25cc6e32f9d17e21712fda57901860dc@ccrma.stanford.edu> Message-ID: <21942d224c068e80b74ef9b083037b2b@ccrma.stanford.edu> Thanks very much for that info. When I moved from cvs to svn in 2017, I didn't save the history. I don't need it myself (I use some scripts which I conjured up in the 90's, for clm/snd initially). From wdouglass at carnegierobotics.com Wed Sep 30 04:19:08 2020 From: wdouglass at carnegierobotics.com (Woody Douglass) Date: Wed, 30 Sep 2020 11:19:08 +0000 Subject: [CM] s7 git repository In-Reply-To: References: <25cc6e32f9d17e21712fda57901860dc@ccrma.stanford.edu>, Message-ID: <6721a06415ea4f6a8bb0a3a5f3eaa851@carnegierobotics.com> Bill, When you're ready, whether you decide to maintain svn history or not, i'll take my repo down and replace it with a link to the gitlab one. Just let me know. -Woody On 2020-09-30 06:35:03-04:00 cmdist-bounces at ccrma.Stanford.EDU wrote: Nice! One thing though: I noticed 3 commits. I think it'd be good to preserve the commit history. There is the "git-svn" tool to convert an existing svn repo to git. My output of "git log --reverse" of the snd svn repo cloned with git-svn. (the output is the same in woody's mirror) commit e88041f23616418181b094a154d6f07e4e1d2860 Author: schottstaedt Date: Mon Oct 9 14:32:43 2017 +0000 init dirs git-svn-id: https://svn.code.sf.net/p/snd/svn1 at 1 b278ec2f-9027-4a79-a958-f306da2c2c68 I got the repo with "git svn clone https://svn.code.sf.net/p/snd/svn1/" (which took a looong time) Don't know if you can "init" the git repo with your local svn repo. Here's the complete documentation https://git-scm.com/docs/git-svn Alternatively, (if woody's repo is up to date) you could clone that, rename the "upstream" branch to "master" and push to gitlab ..Well unless the "clean state" is on purpose On Wed, 30 Sep 2020 at 11:53, > wrote: With help from Fernando, there is now a git repository for s7: git at cm-gitlab.stanford.edu:bil/s7.git https://cm-gitlab.stanford.edu/bil/s7.git _______________________________________________ Cmdist mailing list Cmdist at ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Wed Sep 30 10:58:21 2020 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 30 Sep 2020 10:58:21 -0700 Subject: [CM] with-sound keywords from grace In-Reply-To: <3574F6A8-728D-4BE9-AAA1-76EA175E7963@zkm.de> References: <3574F6A8-728D-4BE9-AAA1-76EA175E7963@zkm.de> Message-ID: in with-sound ( :output ?test.aiff" :statistics #t I think the first double-quote is a utf-8 character, not an ascii double-quote -- could that be the problem? From lb at zkm.de Wed Sep 30 13:25:15 2020 From: lb at zkm.de (=?utf-8?Q?ludger_br=C3=BCmmer?=) Date: Wed, 30 Sep 2020 22:25:15 +0200 Subject: [CM] with-sound keywords from grace In-Reply-To: References: <3574F6A8-728D-4BE9-AAA1-76EA175E7963@zkm.de> Message-ID: <67F8B67B-BF35-4BD9-9744-37DF2135D6E8@zkm.de> Dear Bil thank you for you Eagles Eyes, but that was an autocorrect which did not occur in the program code. So it is something different. But the malfunction was calling CLM from an Grace Process while the CLM Code with with-sound worked correct. viele Gr??e / all the best Ludger Br?mmer -- Prof. Ludger Br?mmer Leitung | Head of Department Hertz-Labor | Hertz-Lab Professor f?r Komposition f?r digitale Medien Musikhochschule Trossingen, mh-trossingen.de /////// / |< ||| | ZKM | Zentrum f?r Kunst und Medien Karlsruhe /////// / |< ||| | ZKM | Center for Art and Media Karlsruhe /////// / |< ||| | ZKM | Centre d'Art et des M?dias Karlsruhe Lorenzstr. 19, D-76135 Karlsruhe Tel +49-(0)721-8100-1601, Fax +49-(0)721-8100-1699 E-Mail: ludger.bruemmer at zkm.de www.zkm.de Aktuelle Ausstellungen ? current exhibitions > Am 30.09.2020 um 19:58 schrieb bil at ccrma.stanford.edu : > > in > > with-sound ( :output ?test.aiff" > :statistics #t > > I think the first double-quote is a utf-8 character, not > an ascii double-quote -- could that be the problem? > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: zkm-cz.jpg Type: image/jpeg Size: 41457 bytes Desc: not available URL: From taube at illinois.edu Wed Sep 30 14:01:28 2020 From: taube at illinois.edu (Taube, Heinrich K) Date: Wed, 30 Sep 2020 21:01:28 +0000 Subject: [CM] with-sound keywords from grace In-Reply-To: <67F8B67B-BF35-4BD9-9744-37DF2135D6E8@zkm.de> References: <3574F6A8-728D-4BE9-AAA1-76EA175E7963@zkm.de> <67F8B67B-BF35-4BD9-9744-37DF2135D6E8@zkm.de> Message-ID: Hi Ludi! I am able to reproduce the bug with your example code Ill take a look at it? ?Rick On Sep 30, 2020, at 3:25 PM, ludger br?mmer > wrote: Dear Bil thank you for you Eagles Eyes, but that was an autocorrect which did not occur in the program code. So it is something different. But the malfunction was calling CLM from an Grace Process while the CLM Code with with-sound worked correct. viele Gr??e / all the best Ludger Br?mmer -- Prof. Ludger Br?mmer Leitung | Head of Department Hertz-Labor | Hertz-Lab Professor f?r Komposition f?r digitale Medien Musikhochschule Trossingen, mh-trossingen.de /////// / |< ||| | ZKM | Zentrum f?r Kunst und Medien Karlsruhe /////// / |< ||| | ZKM | Center for Art and Media Karlsruhe /////// / |< ||| | ZKM | Centre d'Art et des M?dias Karlsruhe Lorenzstr. 19, D-76135 Karlsruhe Tel +49-(0)721-8100-1601, Fax +49-(0)721-8100-1699 E-Mail: ludger.bruemmer at zkm.de www.zkm.de Aktuelle Ausstellungen ? current exhibitions Am 30.09.2020 um 19:58 schrieb bil at ccrma.stanford.edu >: in with-sound ( :output ?test.aiff" :statistics #t I think the first double-quote is a utf-8 character, not an ascii double-quote -- could that be the problem? _______________________________________________ Cmdist mailing list Cmdist at ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist _______________________________________________ Cmdist mailing list Cmdist at ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Wed Sep 30 14:50:21 2020 From: iainduncanlists at gmail.com (Iain Duncan) Date: Wed, 30 Sep 2020 14:50:21 -0700 Subject: [CM] Speaking of bugs Message-ID: A few months ago I reported that I couldn't get loop to work properly on windows, just wondering if anyone (Rick?) ever figured out what was up there. I'm happy to help debug if you need testers with both windows and osx access iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From orm.finnendahl at selma.hfmdk-frankfurt.de Wed Sep 30 23:38:51 2020 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Thu, 01 Oct 2020 08:38:51 +0200 Subject: [CM] Speaking of bugs In-Reply-To: References: Message-ID: <9AD0305B-73A5-4E48-A74E-F8D3D4B4643B@selma.hfmdk-frankfurt.de> Hi Iain, I fixed a couple of loop bugs in cm's common lisp code some years ago. It's apparently the same code base as rthe s7 code If those are the bugs you were hitting, I can provide you with information what's causing it after next Wednesday when I'm back on my computer. The bug has to do with a wrong sequence of variable initialization. Best, Orm Am 30. September 2020 23:50:21 MESZ schrieb Iain Duncan : >A few months ago I reported that I couldn't get loop to work properly >on >windows, just wondering if anyone (Rick?) ever figured out what was up >there. I'm happy to help debug if you need testers with both windows >and >osx access > >iain ---------------------------------------------------------------------- Prof. Orm Finnendahl Komposition Hochschule f?r Musik und Darstellende Kunst Eschersheimer Landstr. 29-39 60322 Frankfurt am Main https://www.youtube.com/watch?v=2rWha1HTfFE&list=PLiGfneJSWmNw6dTUvcTHbTkCYOOTiB_N6 -------------- next part -------------- An HTML attachment was scrubbed... URL: