Hi Risto,
> Is this just a limitation of the current version?
The original plan was for Moselle to be limited to patching between
modules--but to be the best within this narrow niche. It wasn't a
goal to do 1) composition, 2) module design (eg, build novel filters
and oscillators from scratch) o
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 wrote:
>> http://moselle.invisionzone.com/index.php?/blog/1/entry-18-sampl
> 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 w
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 suggesti
> 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 Nyq
> This question has probably come up before: How does your language
> compare to FAUST?
Hi Thomas,
Thank you for your interest. Your questions alone have already taught me a lot.
Since you know FAUST well, and Moselle's hopefully easy to read, maybe
a quick glance at this example would tell you
> (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/softwa
On 1/13/14 11:50 AM, Charles Z Henry wrote:
On Mon, Jan 13, 2014 at 3:24 AM, Dave Gamble 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
On Mon, Jan 13, 2014 at 3:24 AM, Dave Gamble 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 li
On Mon, Jan 13, 2014 at 2:24 PM, Thomas Strathmann 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 e
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
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.
H_lp(e^iw) =1 for |w| Ref: Pg 78, DIscrete-time Signal Processing, 2nd ed.
> Oppenheim, Schafer
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 di
13 matches
Mail list logo
