Re: [music-dsp] Moselle Alpha 0.1.3 Released
Hi, Would you say the emphasis of the software you're making is on the structure of the algorithms, or more on the sound quality at the output ? There are a lot of blocks available in general, as a good example the freely available open source Ladspa plugins, did you think of using those, and did you think about sampling issues, when making signal graphs like in the example ? gr. T.V. Hi Theo, At this point, the #1 goal is to evaluate the language itself. Is a functional, textual, programming language the best way to design a patch? Better than Csound, better than visual environments like Buzz or Cycling '74's Max? Can I write a patch in Moselle that someone with no Moselle experience can understand at a glance? Can I write one that even a Max expert understands better than the same sound written in Max? I THINK so, but I haven't heard any feedback on this yet. Now, to entice people to even try it out, I've actually had to provide about 15+ different module types: naive oscillator, BWL oscillator, envelope, filter, slew, tuning tables, maps, noise, sample/hold etc. I've also developed what I think is a very good development editor, that highlights comments, puts errors in red, etc. But at this point, while I think its all pretty good, its almost disposable in that some of it could be replaced by stronger public-domain modules or modules from a commercial vendor. A lot of it would need re-writing on Mac, etc. So despite the fact its pretty finished, its still at heart an scientific experiment to answer the question: is this textual, functional language the best way to design and support patches? If this is answered even in the negative, that'd be quite interesting. But if its answered in the positive, then the #2 goal of course would be to sound great and see it in use. I haven't looked too much at 3rd-party modules yet (though I'm spending today evaluating some public-domain filters.) Part of the reason is that Moselle's own modules, such as the Delay, the Envelope, and the SWO (stored-waveform oscillator) have special features that I wanted to try and get feedback on, rather than use some off-the-shelf module. The other part of the reason is that I thought I could meet Goal #1 with only about one module with DSP knowedge in it, for which I used a publicly-available Butterworth filter. Also, I'm open to commercial collaboration: some team of DSP experts that has good modules may want to use Moselle's patching language. This could be the case for hardware or software, synthesis or DSP. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Moselle Alpha 0.1.3 Released
On 13.01.14 09:46, Frank Sheeran wrote: At this point, the #1 goal is to evaluate the language itself. Is a functional, textual, programming language the best way to design a patch? Better than Csound, better than visual environments like Buzz or Cycling '74's Max? Can I write a patch in Moselle that someone with no Moselle experience can understand at a glance? Can I write one that even a Max expert understands better than the same sound written in Max? I THINK so, but I haven't heard any feedback on this yet. This question has probably come up before: How does your language compare to FAUST? FAUST is quite elegant because it has an underlying formal semantics in terms of an algebra of data flow graphs, but the resulting programs (even simple examples) are hard to read because of the inherent impedance mismatch you run into when trying to describe arbitrary directed graphs (especially those with cycles) in a linear format. I guess the question I'm really interested in here is: How does your language attack this basic problem. Just one more question: Is there a a formal semantics? And if not, do you plan to provide one once the design has sufficiently stabilised? I'd expect something along those lines given that you seem to put a strong emphasis on the functional aspects of your language. Do you support equational reasoning? Do you have support for rewriting your signal flow graphs without changing their semantics? I looked at http://moselle.invisionzone.com/ and could not find any language documentation. Is there any? Late to the party and somewhat curious, Thomas -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Moselle Alpha 0.1.3 Released
On Mon, Jan 13, 2014 at 2:24 PM, Thomas Strathmann tho...@pdp7.org wrote: On 13.01.14 09:46, Frank Sheeran wrote: At this point, the #1 goal is to evaluate the language itself. Is a functional, textual, programming language the best way to design a patch? Better than Csound, better than visual environments like Buzz or Cycling '74's Max? Can I write a patch in Moselle that someone with no Moselle experience can understand at a glance? Can I write one that even a Max expert understands better than the same sound written in Max? I THINK so, but I haven't heard any feedback on this yet. This question has probably come up before: How does your language compare to FAUST? FAUST is quite elegant because it has an underlying formal semantics in terms of an algebra of data flow graphs, but the resulting programs (even simple examples) are hard to read because of the inherent impedance mismatch you run into when trying to describe arbitrary directed graphs (especially those with cycles) in a linear format. I guess the question I'm really interested in here is: How does your language attack this basic problem. Actully, I have basically the same question. Have you evaluated/investigated Common Lisp Music (https://ccrma.stanford.edu/software/clm/clm/clm.html)? A couple of years ago I took a course in Nyquist (http://www.cs.cmu.edu/~music/nyquist/), which I believe is based on Lisp. I found Nyquist to be quite powerful, althought I always found myself writing very complicated structures instead of composing scores, but maybe that's just because I'm such a nerd ;) Stefan -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Square-summability for the ideal low pass filter
On Mon, Jan 13, 2014 at 3:24 AM, Dave Gamble davegam...@gmail.com wrote: Hi, Don't post MS word files to the list. Learn latex notation and use it as plain text. Any replies you get will be latex style, as is mine below. I do agree that MS word files would be hard to read for some (especially since MS likes to change those formats every so often and you can't always count on FOSS tools to read them). Some others will just be unwilling. However, not all replies will be latex style. Dave speaks only for himself. It's not a rule of the list. I like this tool: http://www.codecogs.com/latex/eqneditor.php It should make latex replies simpler if you're not familiar or don't have decent tools installed on your computer. Chuck -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Moselle Alpha 0.1.3 Released
(https://ccrma.stanford.edu/software/clm/clm/clm.html) I haven't worked much on the common lisp version of clm in the last 10 years -- Rick Taube (Common Music, Grace) and I moved to scheme (another language in the lisp family). So the up-to-date reference is: https://ccrma.stanford.edu/software/snd/snd/snd.html which has links to s7.html, sndclm.html etc. The synatx and basic ideas are the same as in the common lisp version. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Square-summability for the ideal low pass filter
Didnt mean to start a religious war. ASCII, latex, whatever, same deal. Anything that can be read in the body of the email be anyone. Attachments struck me as lazy. Correct me on my maths, not my hasty advice regarding how to write emails that are likely to be understood here. Consider my suggestion retracted. On Monday, 13 January 2014, robert bristow-johnson wrote: On 1/13/14 11:50 AM, Charles Z Henry wrote: On Mon, Jan 13, 2014 at 3:24 AM, Dave Gambledavegam...@gmail.com wrote: Don't post MS word files to the list. Learn latex notation and use it as plain text. Any replies you get will be latex style, as is mine below. oh? I do agree that MS word files would be hard to read for some (especially since MS likes to change those formats every so often and you can't always count on FOSS tools to read them). Some others will just be unwilling. However, not all replies will be latex style. Dave speaks only for himself. It's not a rule of the list. i dunno if Douglas made the list into anything other than plain text or not, but i am assuming it's still plain ASCII as are the USENET newsgroups, like comp.dsp. i post using ASCII math (distant cousin to ASCII art). i assume the reader will be reading with a mono-spaced font and i use spaces, not tabs. so reading any math posted from me should be reasonably apparent. reading LaTeX and translating that in my brain is a pain in the arse. even at the Signal Processing Stack Exchange, where LaTeX support is provided, it's a real pain-in-arse to set up every reply using the math pasteup, but i do it. here, ASCII math is good enough, me thinks. no one needs to post in LaTeX and, if you want people to read your math readily, i would not recommend posting in LaTeX. but if the topic is important or interesting to me, i *may* choose to translate the LaTeX in my head. but i don't wanna do that. -- r b-j r...@audioimagination.com Imagination is more important than knowledge. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Moselle Alpha 0.1.3 Released
According to the wisdom of XKCD, Functional programming combines the flexibility and power of abstract mathematics with the intuitive clarity of abstract mathematics. ;-) On Jan 13, 2014, at 3:51 PM, Risto Holopainen rist...@hotmail.com wrote: http://moselle.invisionzone.com/index.php?/blog/1/entry-18-sample-module/ A quick question for you is that with your obvious expertise, can you follow these at all? I don't know very much functional programming and find it a bit difficult to guess what the code is doing, even knowing what it's supposed to do. The IF statements seem to have the conditional followed by the true and false branches in the parantheses, right? Apart from that, the syntax isn't too obvious. But maybe it is very simple if you read the manual or some examples. Moselle doesn't support feedback, history values (eg z-1), or the data types and control structures you'd need to write things like the Envelope or Delay. Is this just a limitation of the current version? I find feedback and access to previous sample values to be necessary for doing what I am used to do (I'm using csound and C++). Have you had a look at other text based synthesis environments such as ChucK or SuperCollider? I think the latter at least has a thriving user community. Risto Holopainen -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
