From taube at uiuc.edu Sat Aug 1 09:06:54 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Sat, 1 Aug 2009 11:06:54 -0500 Subject: [CM] file drag and drop support Message-ID: adding final touches to release -- grace now has drag and drop support for the file types it knows about. you can drag file(s) onto the application icon or onto the Console window once the app is running. the files are handled like this: .scm .sal .ins .clm .fms open file in editor window .xml open file in plot window .mid open midi file in plot window From aykut_caglayan at yahoo.com Sat Aug 1 10:30:17 2009 From: aykut_caglayan at yahoo.com (Aykut Caglayan) Date: Sat, 1 Aug 2009 10:30:17 -0700 (PDT) Subject: [CM] juce debug lib Message-ID: <80351.34239.qm@web45708.mail.sp1.yahoo.com> Hallo Rick! i try to shift to cm3, but have some problems. Macintosh:CM3 iKut$ premake --target gnu --juce /Users/iKut/CM3/juce --sndlib /Users/iKut/CM3/sndlib WARNING: no juce debug lib found for CONFIG=Debug WARNING: no juce debug lib found for CONFIG=Debug Generating GNU makefiles: ....cm ....grace Macintosh:CM3 iKut$ make ==== Building cm ==== make[1]: *** No rule to make target `src/Scanner.cpp', needed by `obj/cm/Release/Scanner.o'. Stop. make: *** [cm] Error 2 Should i build juce using Xcode?(i tried it before, but couldn't handle several errors) thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From ja.lira0 at gmail.com Mon Aug 3 18:20:42 2009 From: ja.lira0 at gmail.com (James) Date: Mon, 3 Aug 2009 21:20:42 -0400 Subject: [CM] Snd-Emacs Problems Message-ID: I recently compiled snd-10 from daily sources with the default S7-scheme. I'm trying to get it working in emacs. See my .emacs below. I'm not sure how to set the program-name variables. Is snd-s7 an executable? (add-to-list 'load-path "~/bin/snd-10/") (autoload 'run-snd-scheme "inf-snd" "Start inferior Snd-Scheme process" t) (autoload 'run-snd-ruby "inf-snd" "Start inferior Snd-Ruby process" t) (autoload 'run-snd-forth "inf-snd" "Start inferior Snd-Forth process" t) (autoload 'snd-scheme-mode "inf-snd" "Load snd-scheme-mode." t) (autoload 'snd-ruby-mode "inf-snd" "Load snd-ruby-mode." t) (autoload 'snd-forth-mode "inf-snd" "Load snd-forth-mode." t) ;; ;; These variables should be set to your needs! ;; (setq inf-snd-scheme-program-name "snd-s7 -notehook") ;; (setq inf-snd-ruby-program-name "snd-ruby -notebook") ;; (setq inf-snd-forth-program-name "snd-forth") (setq inf-snd-working-directory "~/bin/snd-10/") (setq inf-snd-index-path "~/bin/snd-10/") ;; inf-snd-prompt-char ">" listener prompt ;; snd-ruby-mode-hook nil to customize snd-ruby-mode ;; snd-scheme-mode-hook nil to customize snd-scheme-mode ;; snd-forth-mode-hook nil to customize inf-snd-forth-mode Emacs loads everything with no errors but when I try to switch to snd-scheme mode the *Message* buffer gives me this: Loading /home/james/bin/snd-10/inf-snd.el (source)... eval-buffer: Cannot open load file: ruby-mode -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at fth-devel.net Mon Aug 3 23:30:56 2009 From: mike at fth-devel.net (Michael Scholz) Date: Tue, 04 Aug 2009 08:30:56 +0200 Subject: [CM] Snd-Emacs Problems In-Reply-To: (James's message of "Mon\, 3 Aug 2009 21\:20\:42 -0400") References: Message-ID: <8663d4t7j3.fsf@pumpkin.fth-devel.net> James writes: > I recently compiled snd-10 from daily sources with the default S7-scheme. I'm > trying to get it working in emacs. > [...] > Emacs loads everything with no errors but when I try to switch to snd-scheme > mode the *Message* buffer gives me this: > > Loading /home/james/bin/snd-10/inf-snd.el (source)... > eval-buffer: Cannot open load file: ruby-mode inf-snd.el is prepared to work with snd-scheme, snd-ruby, and snd-forth so it expects more than the usual libraries delivered with Emacs. You will find ruby-mode.el and inf-ruby.el in any ftp://ftp.ruby-lang.org/pub/ruby/ruby-*.tar.gz and gforth.el in ftp://ftp.gnu.org/pub/gnu/gforth/gforth-0.[67].*.tar.gz. Sorry for the confusion. Mike From ja.lira0 at gmail.com Tue Aug 4 06:04:29 2009 From: ja.lira0 at gmail.com (James) Date: Tue, 4 Aug 2009 09:04:29 -0400 Subject: [CM] Snd-Emacs Problems In-Reply-To: <8663d4t7j3.fsf@pumpkin.fth-devel.net> References: <8663d4t7j3.fsf@pumpkin.fth-devel.net> Message-ID: Thanks Mike. I downloaded the three .el files for Forth and Ruby. How would I then update my .emacs. I copied them to /etc/emacs/site-start.d/ but emacs didn't load them. Thanks, James On Tue, Aug 4, 2009 at 2:30 AM, Michael Scholz wrote: > James writes: > > I recently compiled snd-10 from daily sources with the default S7-scheme. > I'm > > trying to get it working in emacs. > > [...] > > Emacs loads everything with no errors but when I try to switch to > snd-scheme > > mode the *Message* buffer gives me this: > > > > Loading /home/james/bin/snd-10/inf-snd.el (source)... > > eval-buffer: Cannot open load file: ruby-mode > > inf-snd.el is prepared to work with snd-scheme, snd-ruby, and snd-forth > so it expects more than the usual libraries delivered with Emacs. You > will find ruby-mode.el and inf-ruby.el in any > ftp://ftp.ruby-lang.org/pub/ruby/ruby-*.tar.gz and gforth.el in > ftp://ftp.gnu.org/pub/gnu/gforth/gforth-0.[67].*.tar.gz > . > > Sorry for the confusion. > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at fth-devel.net Tue Aug 4 11:19:33 2009 From: mike at fth-devel.net (Michael Scholz) Date: Tue, 04 Aug 2009 20:19:33 +0200 Subject: [CM] Snd-Emacs Problems In-Reply-To: (James's message of "Tue\, 4 Aug 2009 09\:04\:29 -0400") References: <8663d4t7j3.fsf@pumpkin.fth-devel.net> Message-ID: <864osnsaq2.fsf@pumpkin.fth-devel.net> James writes: > I downloaded the three .el files for Forth and Ruby. How would I then update > my .emacs. > > I copied them to /etc/emacs/site-start.d/ but emacs didn't load them. /etc/emacs/site-start.d/ is in your load-path, isn't it? If you don't use forth or ruby code, you shouldn't do anything in your ~/.emacs (I think). I copied the *.el files to ${prefix}/share/emacs/site-lisp which is automatically in load-path and have the following in ~/.emacs: (autoload 'ruby-mode "ruby-mode" "Mode for editing ruby source files" t) (autoload 'run-ruby "inf-ruby" "Run an inferior Ruby process" t) (autoload 'inf-ruby-keys "inf-ruby" "Local key defs for inf-ruby in ruby-mode" t) (autoload 'forth-mode "gforth" "Major mode Forth." t) (autoload 'forth-block-mode "gforth" "Major mode Forth." t) (autoload 'inferior-forth-mode "gforth" "Major mode Forth." t) (setq forth-jit-parser nil) ;too slow (setq forth-use-objects nil) (setq forth-use-oof nil) (setq forth-hilight-level 3) (setq forth-indent-level 2) (setq forth-minor-indent-level 1) (setq forth-custom-words '((("instrument:" "event:") definition-starter (font-lock-keyword-face . 1) "[ \t\n]" t name (font-lock-function-name-face . 3)) (("lambda:" "let:") definition-starter (font-lock-keyword-face . 1)) ((";instrument" ";event" ";let" ";proc") definition-ender (font-lock-keyword-face . 1)) ((".\\\"") compile-only (font-lock-string-face . 1) "[^\\][\"\n]" nil string (font-lock-string-face . 1)) (("unless" "?dup-not-if" "?dup-unless" "run" "run-instrument" "end-run" "each" "end-each" "map" "map!" "end-map") compile-only (font-lock-keyword-face . 2)) (("array(" "#(" "assoc(" "#a(" "hash{" "#{" "list(" "'(" "alist(" "'a(" "gdbm{" "}" "vct(" ")" "make-?obj") non-immediate (font-lock-keyword-face . 2)) (("[defined]" "[undefined]" "defined?") immediate (font-lock-keyword-face . 2) "[ \t\n]" t name (font-lock-function-name-face . 3)) (("create-hook" "create-symbol" "create-keyword" "create-exception") non-immediate (font-lock-type-face . 2) "[ \t\n]" t name (font-lock-variable-name-face . 3)) (("[unless]" "[i]" "[each]" "[map]" "[end-each]" "[end-map]") immediate (font-lock-keyword-face . 2)) (("+to") immediate (font-lock-keyword-face . 2) "[ \t\n]" t name (font-lock-variable-name-face . 3)) (("nil" "undef" "#t" "#f" "two-pi" "half-pi" "float" "double" "a/o" "r/a") non-immediate (font-lock-constant-face . 1)) ("[-0-9.+]+[-/+]?[-0-9.+]+i?" non-immediate (font-lock-constant-face . 1)) (("<'>" "<'set>") immediate (font-lock-keyword-face . 2) "[ \t\n]" t name (font-lock-function-name-face . 3)) (("") immediate (font-lock-keyword-face . 1) "[ \t\n]" t string (font-lock-string-face . 1)) ("[<{]{" non-immediate (font-lock-variable-name-face . 1) "}[>}]" nil string (font-lock-variable-name-face . 1)) (("}>" "}") compile-only (font-lock-variable-name-face . 1 )) (":\\sw+" non-immediate (font-lock-builtin-face . 1)) ;keywords ("'[^( ]\\sw+" non-immediate (font-lock-constant-face . 1)) ;symbols ("\*[^ ]+.+\*" immediate (font-lock-variable-name-face . 1)) ;global variables ("\".*[^\\]\"" immediate (font-lock-string-face . 1)) ;string "" (w/o space) ("\/.*[^\\]\/" immediate (font-lock-string-face . 1)) ;regexp // (w/o space) (("s\\\"" "c\\\"" "$\"" "doc\"") immediate (font-lock-string-face . 1) "[^\\]\"" nil string (font-lock-string-face . 1)) (("re\/") immediate (font-lock-string-face . 1) "[^\\]\/" nil string (font-lock-string-face . 1)) (("defines") non-immediate (font-lock-type-face . 2) "[ \t\n]" t name (font-lock-function-name-face . 3)) (("dl-load") non-immediate (font-lock-keyword-face . 1) "[\n\t ]" t string (font-lock-string-face . 1) "[\n\t ]" t string (font-lock-string-face . 1)) (("lambda-create" "proc-create") non-immediate (font-lock-type-face . 2) nil))) (setq forth-custom-indent-words '((("instrument:" "event:" "lambda:" "let:" "unless" "?dup-not-if" "?dup-unless" "[unless]" "run" "run-instrument" "each" "map" "map!" "map" "[each]" "[map]") (0 . 2) (0 . 2)) (("end-run" "end-map" "end-each" "[end-each]" "[end-map]" ";instrument" ";event" ";let" ";proc") (-2 . 0) (0 . -2)) (("<{") (0 . 3) (0 . 3)) (("}>") (-3 . 0) (0 . -3)) (("array(" "#(" "assoc(" "#a(" "hash{" "#{" "list(" "'(" "alist(" "'a(" "gdbm{" "vct(" "<{") (0 . 3) (0 . 3)) ((")" "}") (-3 . 0) (0 . -3)) (("does>") (-1 . 1) (0 . 0)))) Mike From ja.lira0 at gmail.com Tue Aug 4 17:16:08 2009 From: ja.lira0 at gmail.com (James) Date: Tue, 4 Aug 2009 20:16:08 -0400 Subject: [CM] Snd-Emacs Problems In-Reply-To: <864osnsaq2.fsf@pumpkin.fth-devel.net> References: <8663d4t7j3.fsf@pumpkin.fth-devel.net> <864osnsaq2.fsf@pumpkin.fth-devel.net> Message-ID: This seems to be working now. I commented out the forth and ruby autoloads since I will only be using Scheme. Even with these commented out, emacs was still giving me this error: Cannot open load file: ruby-mode I moved the ruby and forth .els to /usr/share/emacs.. I thought /etc/emacs/site-start.d/ was in the load-path but now that they're in /usr/share everything seems to work okay. I also had to set this variable to just "snd" ;; (setq inf-snd-scheme-program-name "snd-s7 -notehook") -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.s.matheussen at notam02.no Wed Aug 5 03:02:06 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed, 5 Aug 2009 12:02:06 +0200 (CEST) Subject: [CM] [ANN] New beta of Snd-ls Message-ID: Snd-ls is a distribution of Snd with more features enabled than in the default distribution. Snd-ls is also required for running the San-dysth soft synth (http://users.notam02.no/~kjetism/sandysth/), and it is the recommended distribution to use with the Snd-rt music programming system (http://archive.notam02.no/arkiv/doc/snd-rt/). Changes 0.9.8.17 -> 0.9.9.0_beta: -Updated Snd from 9.3/2007-07-30 to 10.8/2009-08-05. -Brushed up build system a bit. (might be easier to use for package managers now) 0.9.9.0_beta is uploaded here: http://archive.notam02.no/arkiv/src/snd/?C=M;O=D From ja.lira0 at gmail.com Thu Aug 6 17:38:10 2009 From: ja.lira0 at gmail.com (James) Date: Thu, 6 Aug 2009 20:38:10 -0400 Subject: [CM] Snd Selection Behaviour Message-ID: I'm having a problem with snd wherein any command related to selection results in an unbound variable error message. I'm typing the commands as follows: (make-selection :beg 5000 :end 7000) (show-selection) (clear-selection) is there a reason for this? Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From k.s.matheussen at notam02.no Fri Aug 7 01:50:50 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Fri, 7 Aug 2009 10:50:50 +0200 (CEST) Subject: [CM] Snd Selection Behaviour In-Reply-To: References: Message-ID: On Thu, 6 Aug 2009, James wrote: > I'm having a problem with snd wherein any command related to selection > results in an unbound variable error message. > > I'm typing the commands as follows: > > (make-selection :beg 5000 :end 7000) > (show-selection) > (clear-selection) > > is there a reason for this? > Have you loaded selection.scm? From bil at ccrma.Stanford.EDU Sun Aug 9 04:24:19 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 9 Aug 2009 04:24:19 -0700 Subject: [CM] Snd 10.8 Message-ID: <20090809112149.M96083@ccrma.Stanford.EDU> Snd 10.8 Rick fixed the windows build process for sndlib; added sndlib.sln. Kjetil and Mike made numerous improvements. in s7, sound-data, frame, mixer objects are set-applicable (like vectors and vcts). Also strings, lists, and hash-tables are set-applicable. This has the somewhat strange side effect that (apply "hi" '(1)) returns #\i, since strings are applicable. I think the syntax is pretty: (let ((lst (list 1 2 3))) (set! (lst 1) 32) (list (lst 0) (lst 1))) -> '(1 32) (let ((hash (make-hash-table))) (set! (hash 'hi) 32) (hash 'hi)) -> 32 but even better, vector arithmetic is almost readable, and you can write (for example) a generic FFT that can take vectors, vcts, frames, lists, etc. I wonder if I should extend the "setter" idea to things like imag-part or numerator. One thing I haven't looked into yet: (set! ((lst 0) 0) 1) which I guess is set-caar! s7 length is generic, also added generic copy and fill!. added sort! for lists or vectors (it uses C's qsort internally, and list arguments are always copied -- it's really vector-sort!). added frame and mixer, paralleling functions like vct and list: (frame .1 .2) = (make-frame 2 .1 .2) etc added profiling option (--with-profiling in configure) to s7. profile function in extensions.scm. This could be greatly elaborated, if it's of interest. added trace, untrace, break and __func__ to s7. The __func__ info made it possible to remove the backtrace facility altogether: backtracing, backtrace, set-backtrace-length, clear-backtrace, and list-line-number have been removed. These are replaced by the stacktrace function, callable from within a break or error handler. stacktrace (and error position info) still needs a lot of work. added macroexpand. > (define-macro (hi a) `(+ ,a 1)) hi > (macroexpand (hi 32)) (+ 32 1) removed gc-verbose, and load-verbose replaced by *load-hook*. Error handling can be specialized via *error-hook*. C-\ in the Snd terminal breaks out of evaluator infinite loops (s7 only). In the s7 C API: s7_define_function_star: define* at C-level, handling keywords, argument order, etc. s7_define_macro: define a macro at C-level. s7_new_type_x: extended version of the C-level new type creator (length, copy, fill). lower-case versions of s7_T and friends (I'll probably remove the upper-case versions someday). read-hook (in s7-Snd) has changed (the other cases are not changed). the ubiquitous Float type is now named mus_float_t (new sndlib major version: 21), and off_t has been changed to mus_long_t. Wherever possible I'm using either int64_t or long long int, rather than off_t. added all the non-Snd-specific instrument files to the sndlib tarball: analog-filter.scm|rb, animals.scm, bird.scm|rb|fsm, clm.fs, clm-ins.scm|rb|fs, dlocsig.scm|rb, fade.scm, freeverb.scm|rb, generators.scm, grani.scm, jcrev.scm, jcvoi.scm, maraca.scm|rb, maxf.scm|rb, moog.scm, noise.scm|rb, piano.scm|rb, prc95.scm|rb, pvoc.scm|rb, singer.scm|rb, sndwarp.scm, spectr.scm|rb|fs, stochastic.scm, strad.scm|rb, v.scm|rb. Also split out expandn, fullmix, and nrev from clm-ins.scm into separate files. Mike brought the sndins directory up to date. added "encapsulators" to s7: open-encapsulator, close-encapsulator, (obj) to restore, encapsulator-bindings (define-macro (encapsulate . body) (let ((encap (gensym))) `(let ((,encap (open-encapsulator))) (dynamic-wind (lambda () #f) (lambda () , at body) (lambda () ((,encap)) ; restore saved vars (close-encapsulator ,encap)))))) This evaluates "body", then returns any variables global to that code to their prior value: > (define global-x 32) global-x > (encapsulate (set! global-x 123) (format #f "x: ~A" global-x)) "x: 123" > global-x 32 There are three or maybe four reasons for encapsulators (rather than, say, fluid-let). The main one is that it's a neat idea: a sort of data-side continuation. open-encapsulator remembers the overall environment at the point it is called, returning an encapuslator object. Whenever we want to return to that data state, we call that object as a thunk. encapsulator-bindings returns the alist of variables awaiting restoration. Once called, that list is cleared, and the encapsulator starts saving values again (so repeated calls keep returning you to that data state). close-encapsulator turns that encapsulator off. In a REPL, for example, you could save the initial state, then return to it at any time, without restarting the interpreter. fluid-let is not what we want here because it has a body, and requires that you list in advance what variables you want to protect (and besides, it's not really a let (it uses "set!") and I can't see anything fluid about it). By tracing the encapsulator object, we can see every set! within some piece of code. This encapsulation is not complete: I haven't finished making Snd/CLM objects work with it, and some Scheme constructs aren't handled yet: (string-set! (vector-ref...)) for example. Another idea that strikes me as interesting: define! (define! env var value) would bind var to value in the environment env (it changes env, hence the "!"). Currently, if you want 2 functions to share a local variable, you have to establish the names in the outer environment by hand: (define proc1 #f) (define proc2 #f) (let ((local-var 32)) (set! proc1 (lambda () (+ local-var 1))) (set! proc2 (lambda () (- local-var 1)))) You can't use (begin (define local-var 23) (define (proc1) (+ local-var 1)) (define (proc2) (- local-var 1))) because local-var is also defined outside the "begin". With define! you could: (let ((e (current-environment))) ; or (global-environment) to make them global (let ((local-var 32)) (define! e (proc1) (+ local-var 1)) (define! e (proc2) (- local-var 1)))) This could replace the notions of library and module, I think. A file could be enclosed in a let, keeping everything local to that file except stuff that is defined via define!. Or... (env-let env (...) body) evaluates its bindings and body in the context of the environment env. Or environments as "first class" objects (see extend-environment in s7.h, for example). Or... One last idea: emacs 23 apparently supports the XEmbed protocol, so I think it is now possible to do what I had hoped to do in 1996: use emacs as the snd listener (within Snd). To communicate between Snd and Emacs it might still be necessary to treat Snd as an emacs subjob, but the emacs window would be inside the Snd app. cmn works in ECL 9.7.1. ruby 1.9 works as Snd's extension language. guile 1.9 works, but is not very useful: the run macro does not work, nor does ws.scm. using Motif 2.3.2 (CVS at sourceforge), the listener is at the top for some reason. Checked: gtk 2.17.3|4|5|6, fth 1.2.5|6, fftw 3.2.2, guile 1.9.1, openmotif 2.3.2, clisp 2.48, autoconf 2.64, sbcl 1.0.30, ecl 9.7.1 Thanks!: Mike Scholz, Rick Taube, Kjetil Matheussen, Markus Eichhoff, W Andrew Burnson From taube at uiuc.edu Sun Aug 9 05:15:35 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Sun, 9 Aug 2009 07:15:35 -0500 Subject: [CM] Snd 10.8 In-Reply-To: <20090809112149.M96083@ccrma.Stanford.EDU> References: <20090809112149.M96083@ccrma.Stanford.EDU> Message-ID: On Aug 9, 2009, at 6:24 AM, Bill Schottstaedt wrote: > removed gc-verbose, and load-verbose replaced by *load-hook*. Error > handling can > be specialized via *error-hook*. and the error hook works great! now scheme error messages look just like my other (C) error messages, even if the error is a built in s7 error. s7 is an amazing piece of work! > added macroexpand. > (define-macro (hi a) `(+ ,a 1)) say i noticed yesteday that it seems like macros are expanded every time a function that contains them is evalled -- is that the way it works? (i thought they got expanded only one time) From bil at ccrma.Stanford.EDU Sun Aug 9 05:47:22 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 9 Aug 2009 05:47:22 -0700 Subject: [CM] Snd 10.8 In-Reply-To: References: <20090809112149.M96083@ccrma.Stanford.EDU> Message-ID: <20090809124709.M58324@ccrma.Stanford.EDU> > (i thought they got expanded only one time) me too -- I'll check this. From taube at uiuc.edu Sun Aug 9 05:57:34 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Sun, 9 Aug 2009 07:57:34 -0500 Subject: [CM] Snd 10.8 In-Reply-To: <20090809124709.M58324@ccrma.Stanford.EDU> References: <20090809112149.M96083@ccrma.Stanford.EDU> <20090809124709.M58324@ccrma.Stanford.EDU> Message-ID: <84275D87-0384-418F-B230-1171B3753632@uiuc.edu> Im expecting to see the "expanding foo macro!" message only one time. but maybe im confused! that is i thought the macro got expanded when 'define' did its work, not when i call the function. (define-macro (foo . args) (format #t "expanding foo macro!~%") `(list , at args)) (define (usefoo a b c) (foo a b c)) cm> (usefoo 1 2 3) expanding foo macro! (1 2 3) cm> (usefoo 1 2 3) expanding foo macro! (1 2 3) cm> (usefoo 1 2 3) expanding foo macro! (1 2 3) cm> From k.s.matheussen at notam02.no Sun Aug 9 07:22:15 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Sun, 9 Aug 2009 16:22:15 +0200 (CEST) Subject: [CM] Snd 10.8 In-Reply-To: <84275D87-0384-418F-B230-1171B3753632@uiuc.edu> References: <20090809112149.M96083@ccrma.Stanford.EDU> <20090809124709.M58324@ccrma.Stanford.EDU> <84275D87-0384-418F-B230-1171B3753632@uiuc.edu> Message-ID: On Sun, 9 Aug 2009, Heinrich Taube wrote: > Im expecting to see the "expanding foo macro!" message only one time. > but maybe im confused! > that is i thought the macro got expanded when 'define' did its work, > not when i call the function. > > (define-macro (foo . args) > (format #t "expanding foo macro!~%") > `(list , at args)) > > (define (usefoo a b c) > (foo a b c)) > > cm> (usefoo 1 2 3) > expanding foo macro! > (1 2 3) > cm> (usefoo 1 2 3) > expanding foo macro! > (1 2 3) > cm> (usefoo 1 2 3) > expanding foo macro! > (1 2 3) > cm> > I'm pretty sure this is the common behavior for lisp interpreters. I even think the common lisp standard require implementations to evaluate the macros every time they are interpreted. (?) Besides making it easier to give better debug trace plus making it easier to redefine macros, this behaviour also gives some interesting possibilities. My head hurts a little bit now, but I think the whole rt compiling system in rt-compiler.scm depends on macros to be expanded during evaluation, although I'm not able to figure out how things work right now. But there are of course ways to optimize the macro expansion. Guile, for instance, memoize expanded code, if I remember correctly. From k.s.matheussen at notam02.no Sun Aug 9 07:40:33 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Sun, 9 Aug 2009 16:40:33 +0200 (CEST) Subject: [CM] Snd 10.8 In-Reply-To: References: <20090809112149.M96083@ccrma.Stanford.EDU> <20090809124709.M58324@ccrma.Stanford.EDU> <84275D87-0384-418F-B230-1171B3753632@uiuc.edu> Message-ID: On Sun, 9 Aug 2009, Kjetil S. Matheussen wrote: > > > On Sun, 9 Aug 2009, Heinrich Taube wrote: > >> Im expecting to see the "expanding foo macro!" message only one time. >> but maybe im confused! >> that is i thought the macro got expanded when 'define' did its work, >> not when i call the function. >> >> (define-macro (foo . args) >> (format #t "expanding foo macro!~%") >> `(list , at args)) >> >> (define (usefoo a b c) >> (foo a b c)) >> >> cm> (usefoo 1 2 3) >> expanding foo macro! >> (1 2 3) >> cm> (usefoo 1 2 3) >> expanding foo macro! >> (1 2 3) >> cm> (usefoo 1 2 3) >> expanding foo macro! >> (1 2 3) >> cm> >> > > I'm pretty sure this is the common behavior for lisp interpreters. Sorry, that's probably not true. Guile only expands the first time. (even doing it twice, looks like...) guile> (define-macro (foo . args) (display "expanding")(newline) `(list , at args)) guile> (define (usefoo a b c)(foo a b c)) guile> (usefoo 1 2 3) expanding expanding (1 2 3) guile> (usefoo 1 2 3) (1 2 3) guile> (usefoo 1 2 3) (1 2 3) From taube at uiuc.edu Sun Aug 9 07:52:53 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Sun, 9 Aug 2009 09:52:53 -0500 Subject: [CM] Snd 10.8 In-Reply-To: References: <20090809112149.M96083@ccrma.Stanford.EDU> <20090809124709.M58324@ccrma.Stanford.EDU> <84275D87-0384-418F-B230-1171B3753632@uiuc.edu> Message-ID: <4C59BA3D-5C03-46FC-A2C3-D11EF6B79962@uiuc.edu> yes, what i expected is that a macro get processed (expanded) when the lambda that contains it gets READ by s7, ie when 'define' process the (lambda ...) expr before assigning it to the variable. for example here is clisp. it might be the compiler that does it in this case (not sure) but i dont think you need to compile to expand a macro one time $ clisp [1]> (defmacro foo (&rest args) (format t "macroexpanding foo!~%") `(list , at args)) FOO [2]> (defun bar (a b c) (foo a b c)) macroexpanding foo! BAR [3]> (bar 1 2 3) (1 2 3) [4]> (bar 1 2 3) (1 2 3) >> >> I'm pretty sure this is the common behavior for lisp interpreters. > > Sorry, that's probably not true. > Guile only expands the first time. (even doing it twice, looks > like...) > From bil at ccrma.Stanford.EDU Sun Aug 9 10:08:50 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 9 Aug 2009 10:08:50 -0700 Subject: [CM] freshmeat Message-ID: <20090809170745.M43126@ccrma.Stanford.EDU> I am removing Snd from freshmeat. From eichhoff at statistik.tu-dortmund.de Sun Aug 9 10:37:01 2009 From: eichhoff at statistik.tu-dortmund.de (Markus Eichhoff) Date: Sun, 9 Aug 2009 19:37:01 +0200 (CEST) Subject: [CM] freshmeat In-Reply-To: <20090809170745.M43126@ccrma.Stanford.EDU> References: <20090809170745.M43126@ccrma.Stanford.EDU> Message-ID: <37faba3260ef9c9ef655102990164cc5.squirrel@www.statistik.tu-dortmund.de> Congratulations to the new version. But I better stay with the older version. Because if I update everything (cm, grace, sndlib etc. etc.) then perhaps it won't work again. ;-) My version now where copy+paste works fine is good for me. I will write the code now with MATLAB because I had some problems to write the normal distributed random parameters for the inputs of the instrument-calls with Scheme or Grace or whatever... Now I will built normal distributed parameter-vectors (e.g. 20 vor 20 tones)for perhaps 3-4 parameters. Then I will write with Matlab and fwritef(...) the code that I insert then in Grace and execute it and save the wav-files. If somebody knows how the stiffness-table in piano.scm is created, you could mail me, please. I writed to Mr. Van Duyne, but didn't get any answer yet. I don't know where to get information about each parameter of this piano model. In the paper of Mr. Van Duyne about the commuted piano I also don't find any hints. Best regards and a nice sunday evening and good luck with the bugs that won't like to disappear (but they will, I am sure. ;-)) Markus > I am removing Snd from freshmeat. > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > From taube at uiuc.edu Sun Aug 9 11:15:26 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Sun, 9 Aug 2009 13:15:26 -0500 Subject: [CM] freshmeat In-Reply-To: <37faba3260ef9c9ef655102990164cc5.squirrel@www.statistik.tu-dortmund.de> References: <20090809170745.M43126@ccrma.Stanford.EDU> <37faba3260ef9c9ef655102990164cc5.squirrel@www.statistik.tu-dortmund.de> Message-ID: <61037ED4-C56A-4731-BF7F-59AAE7880419@uiuc.edu> did you look at the distrubutions listed in cm.html#Randomness ?? there is a rangauss listed there... if thats not what you want, just add the generator to CmSupport.cpp and ill tie it in since its generally useful. thats easier than always importing stuff from another app and it would help out other users. On Aug 9, 2009, at 12:37 PM, Markus Eichhoff wrote: > Congratulations to the new version. But I better stay with the older > version. Because if I update everything (cm, grace, sndlib etc. > etc.) then > perhaps it won't work again. ;-) My version now where copy+paste works > fine is good for me. > > I will write the code now with MATLAB because I had some problems to > write > the normal distributed random parameters for the inputs of the > instrument-calls with Scheme or Grace or whatever... > Now I will built normal distributed parameter-vectors (e.g. 20 vor 20 > tones)for perhaps 3-4 parameters. Then I will write with Matlab and > fwritef(...) the code that I insert then in Grace and execute it and > save > the wav-files. > > If somebody knows how the stiffness-table in piano.scm is created, you > could mail me, please. I writed to Mr. Van Duyne, but didn't get any > answer yet. I don't know where to get information about each > parameter of > this piano model. In the paper of Mr. Van Duyne about the commuted > piano I > also don't find any hints. > > Best regards and a nice sunday evening and good luck with the bugs > that > won't like to disappear (but they will, I am sure. ;-)) > > Markus > >> I am removing Snd from freshmeat. >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >> > > > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From bil at ccrma.Stanford.EDU Sun Aug 9 11:27:58 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 9 Aug 2009 11:27:58 -0700 Subject: [CM] Snd 10.8 In-Reply-To: <4C59BA3D-5C03-46FC-A2C3-D11EF6B79962@uiuc.edu> References: <20090809112149.M96083@ccrma.Stanford.EDU> <20090809124709.M58324@ccrma.Stanford.EDU> <84275D87-0384-418F-B230-1171B3753632@uiuc.edu> <4C59BA3D-5C03-46FC-A2C3-D11EF6B79962@uiuc.edu> Message-ID: <20090809181949.M55761@ccrma.Stanford.EDU> > a macro get processed (expanded) when the > lambda that contains it gets READ by s7 I think I can implement this, but it will mean that if the macro is not defined at read time, it will be expanded at eval time. I looked at the macro chapter in cLtL2 but they leave these things up to the implementation; "an implementation...has great latitude in deciding when to expand macros". Currently in s7, the quasiquote expression is expanded at macro definition time, but the macro call is expanded when it is evaluated. I think handling it instead in the reader is easier than splicing its result into the caller at eval time (not sure how much this will slow down the reader). From taube at uiuc.edu Sun Aug 9 11:38:33 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Sun, 9 Aug 2009 13:38:33 -0500 Subject: [CM] Snd 10.8 In-Reply-To: <20090809181949.M55761@ccrma.Stanford.EDU> References: <20090809112149.M96083@ccrma.Stanford.EDU> <20090809124709.M58324@ccrma.Stanford.EDU> <84275D87-0384-418F-B230-1171B3753632@uiuc.edu> <4C59BA3D-5C03-46FC-A2C3-D11EF6B79962@uiuc.edu> <20090809181949.M55761@ccrma.Stanford.EDU> Message-ID: <909F35FB-3A45-493D-BFBA-2484D81D3300@uiuc.edu> > > I think I can implement this, but it will mean that if the macro is > not defined at read time, it will be expanded at eval time. that would allow both to happen. > is expanded when it is evaluated. I think handling it instead > in the reader is easier than splicing its result into the caller > at eval time (not sure how much this will slow down the reader). whatever is easier! im happy to pay the price one time (at read time) to avoid it happening every time at eval time. ottherwise ill get rid of some of my macros since they werent intended to be run each time the function runs (like my optkey arg parsing) so for me id much rather pay the piper when the system boots rahter when people are calling things under processes! From eichhoff at statistik.tu-dortmund.de Sun Aug 9 12:47:25 2009 From: eichhoff at statistik.tu-dortmund.de (Markus Eichhoff) Date: Sun, 9 Aug 2009 21:47:25 +0200 (CEST) Subject: [CM] freshmeat In-Reply-To: <61037ED4-C56A-4731-BF7F-59AAE7880419@uiuc.edu> References: <20090809170745.M43126@ccrma.Stanford.EDU> <37faba3260ef9c9ef655102990164cc5.squirrel@www.statistik.tu-dortmund.de> <61037ED4-C56A-4731-BF7F-59AAE7880419@uiuc.edu> Message-ID: Which site do you mean with "cm.html#Randomness" where I may look for rangauss? Yes, of course, you are right. It would help other users. But first I will import it, because I don't know scheme and don't know some commands like num2str(k) (Matlab) in scheme.... so first I will import the code, but then I will try to write it in Grace. I hope it will be possible then. > did you look at the distrubutions listed in cm.html#Randomness ?? > there is a rangauss listed there... > if thats not what you want, just add the generator to CmSupport.cpp > and ill tie it in since its generally useful. thats easier than > always importing stuff from another app and it would help out other > users. > > > On Aug 9, 2009, at 12:37 PM, Markus Eichhoff wrote: > >> Congratulations to the new version. But I better stay with the older >> version. Because if I update everything (cm, grace, sndlib etc. >> etc.) then >> perhaps it won't work again. ;-) My version now where copy+paste works >> fine is good for me. >> >> I will write the code now with MATLAB because I had some problems to >> write >> the normal distributed random parameters for the inputs of the >> instrument-calls with Scheme or Grace or whatever... >> Now I will built normal distributed parameter-vectors (e.g. 20 vor 20 >> tones)for perhaps 3-4 parameters. Then I will write with Matlab and >> fwritef(...) the code that I insert then in Grace and execute it and >> save >> the wav-files. >> >> If somebody knows how the stiffness-table in piano.scm is created, you >> could mail me, please. I writed to Mr. Van Duyne, but didn't get any >> answer yet. I don't know where to get information about each >> parameter of >> this piano model. In the paper of Mr. Van Duyne about the commuted >> piano I >> also don't find any hints. >> >> Best regards and a nice sunday evening and good luck with the bugs >> that >> won't like to disappear (but they will, I am sure. ;-)) >> >> Markus >> >>> I am removing Snd from freshmeat. >>> >>> _______________________________________________ >>> Cmdist mailing list >>> Cmdist at ccrma.stanford.edu >>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >>> >> >> >> >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > > -- Dipl.-Math. Markus Eichhoff Chair of Computational Statistics Faculty of Statistics Technical University of Dortmund 44221 Dortmund Room 826 Phone: +49 (0)231 755 - 5903 Telefax: +49 (0)231 755 - 4387 E-mail: eichhoff at statistik.tu-dortmund.de Web: http://www.statistik.tu-dortmund.de/eichhoff_eng.html From taube at uiuc.edu Sun Aug 9 14:23:38 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Sun, 9 Aug 2009 16:23:38 -0500 Subject: [CM] freshmeat In-Reply-To: References: <20090809170745.M43126@ccrma.Stanford.EDU> <37faba3260ef9c9ef655102990164cc5.squirrel@www.statistik.tu-dortmund.de> <61037ED4-C56A-4731-BF7F-59AAE7880419@uiuc.edu> Message-ID: > > Which site do you mean with "cm.html#Randomness" where I may look > for rangauss? cm/res/doc/cm.html#Randomness if rangauss isnt what you need, just write a C function that returns double floats in whatever this distribution is. then ill tie it into scheme. On Aug 9, 2009, at 2:47 PM, Markus Eichhoff wrote: > Which site do you mean with "cm.html#Randomness" where I may look for > rangauss? > > Yes, of course, you are right. It would help other users. But first > I will > import it, because I don't know scheme and don't know some commands > like > num2str(k) (Matlab) in scheme.... so first I will import the code, but > then I will try to write it in Grace. I hope it will be possible then. > > >> did you look at the distrubutions listed in cm.html#Randomness ?? >> there is a rangauss listed there... >> if thats not what you want, just add the generator to CmSupport.cpp >> and ill tie it in since its generally useful. thats easier than >> always importing stuff from another app and it would help out other >> users. >> >> >> On Aug 9, 2009, at 12:37 PM, Markus Eichhoff wrote: >> >>> Congratulations to the new version. But I better stay with the older >>> version. Because if I update everything (cm, grace, sndlib etc. >>> etc.) then >>> perhaps it won't work again. ;-) My version now where copy+paste >>> works >>> fine is good for me. >>> >>> I will write the code now with MATLAB because I had some problems to >>> write >>> the normal distributed random parameters for the inputs of the >>> instrument-calls with Scheme or Grace or whatever... >>> Now I will built normal distributed parameter-vectors (e.g. 20 vor >>> 20 >>> tones)for perhaps 3-4 parameters. Then I will write with Matlab and >>> fwritef(...) the code that I insert then in Grace and execute it and >>> save >>> the wav-files. >>> >>> If somebody knows how the stiffness-table in piano.scm is created, >>> you >>> could mail me, please. I writed to Mr. Van Duyne, but didn't get any >>> answer yet. I don't know where to get information about each >>> parameter of >>> this piano model. In the paper of Mr. Van Duyne about the commuted >>> piano I >>> also don't find any hints. >>> >>> Best regards and a nice sunday evening and good luck with the bugs >>> that >>> won't like to disappear (but they will, I am sure. ;-)) >>> >>> Markus >>> >>>> I am removing Snd from freshmeat. >>>> >>>> _______________________________________________ >>>> Cmdist mailing list >>>> Cmdist at ccrma.stanford.edu >>>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Cmdist mailing list >>> Cmdist at ccrma.stanford.edu >>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >> >> > > > -- > Dipl.-Math. Markus Eichhoff > > Chair of Computational Statistics > Faculty of Statistics > Technical University of Dortmund > 44221 Dortmund > Room 826 > > Phone: +49 (0)231 755 - 5903 > Telefax: +49 (0)231 755 - 4387 > E-mail: eichhoff at statistik.tu-dortmund.de > Web: http://www.statistik.tu-dortmund.de/eichhoff_eng.html > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From eichhoff at statistik.tu-dortmund.de Mon Aug 10 03:29:36 2009 From: eichhoff at statistik.tu-dortmund.de (Markus Eichhoff) Date: Mon, 10 Aug 2009 12:29:36 +0200 Subject: [CM] stereo-flute, flow-envelope In-Reply-To: References: <20090809170745.M43126@ccrma.Stanford.EDU> <37faba3260ef9c9ef655102990164cc5.squirrel@www.statistik.tu-dortmund.de> <61037ED4-C56A-4731-BF7F-59AAE7880419@uiuc.edu> Message-ID: <4A7FF690.8030006@statistik.tu-dortmund.de> Do I find on the websites of clm, sndlib or somewhere else information how the :flow-envelope '(x,y,z....) is created? Sometimes I see '(0 0 1 1 2 1 3 0) eight numbers inside, sometimes only 4: '(0 1 100 1). Is it something like begin time, duration, Hz, and decay time perhap? And the eight numbers? Is there also ADSR inside? Heinrich Taube schrieb: >> >> Which site do you mean with "cm.html#Randomness" where I may look for >> rangauss? > > cm/res/doc/cm.html#Randomness > > if rangauss isnt what you need, just write a C function that returns > double floats in whatever this distribution is. then ill tie it into > scheme. > > > On Aug 9, 2009, at 2:47 PM, Markus Eichhoff wrote: > >> Which site do you mean with "cm.html#Randomness" where I may look for >> rangauss? >> >> Yes, of course, you are right. It would help other users. But first I >> will >> import it, because I don't know scheme and don't know some commands like >> num2str(k) (Matlab) in scheme.... so first I will import the code, but >> then I will try to write it in Grace. I hope it will be possible then. >> >> >>> did you look at the distrubutions listed in cm.html#Randomness ?? >>> there is a rangauss listed there... >>> if thats not what you want, just add the generator to CmSupport.cpp >>> and ill tie it in since its generally useful. thats easier than >>> always importing stuff from another app and it would help out other >>> users. >>> >>> >>> On Aug 9, 2009, at 12:37 PM, Markus Eichhoff wrote: >>> >>>> Congratulations to the new version. But I better stay with the older >>>> version. Because if I update everything (cm, grace, sndlib etc. >>>> etc.) then >>>> perhaps it won't work again. ;-) My version now where copy+paste works >>>> fine is good for me. >>>> >>>> I will write the code now with MATLAB because I had some problems to >>>> write >>>> the normal distributed random parameters for the inputs of the >>>> instrument-calls with Scheme or Grace or whatever... >>>> Now I will built normal distributed parameter-vectors (e.g. 20 vor 20 >>>> tones)for perhaps 3-4 parameters. Then I will write with Matlab and >>>> fwritef(...) the code that I insert then in Grace and execute it and >>>> save >>>> the wav-files. >>>> >>>> If somebody knows how the stiffness-table in piano.scm is created, you >>>> could mail me, please. I writed to Mr. Van Duyne, but didn't get any >>>> answer yet. I don't know where to get information about each >>>> parameter of >>>> this piano model. In the paper of Mr. Van Duyne about the commuted >>>> piano I >>>> also don't find any hints. >>>> >>>> Best regards and a nice sunday evening and good luck with the bugs >>>> that >>>> won't like to disappear (but they will, I am sure. ;-)) >>>> >>>> Markus >>>> >>>>> I am removing Snd from freshmeat. >>>>> >>>>> _______________________________________________ >>>>> Cmdist mailing list >>>>> Cmdist at ccrma.stanford.edu >>>>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Cmdist mailing list >>>> Cmdist at ccrma.stanford.edu >>>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >>> >>> >> >> >> -- >> Dipl.-Math. Markus Eichhoff >> >> Chair of Computational Statistics >> Faculty of Statistics >> Technical University of Dortmund >> 44221 Dortmund >> Room 826 >> >> Phone: +49 (0)231 755 - 5903 >> Telefax: +49 (0)231 755 - 4387 >> E-mail: eichhoff at statistik.tu-dortmund.de >> Web: http://www.statistik.tu-dortmund.de/eichhoff_eng.html >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > -- Dipl.-Math. Markus Eichhoff Chair of Computational Statistics Faculty of Statistics Technical University of Dortmund 44221 Dortmund Room: M826 Phone: +49 (0)231 755 - 5903 Telefax: +49 (0)231 755 - 4387 E-mail: eichhoff at statistik.tu-dortmund.de Web: http://www.statistik.tu-dortmund.de/eichhoff_eng.html From lievenmoors at gmail.com Mon Aug 10 07:10:09 2009 From: lievenmoors at gmail.com (lieven moors) Date: Mon, 10 Aug 2009 16:10:09 +0200 Subject: [CM] CM3 woes Message-ID: <4A802A41.3070402@gmail.com> Hi, I would like to report again that CM3 is still completely useless to me, due to problems with midi timing. I'm working on Linux (Ubuntu Studio), and I've tried a lot in order to localize the problem on my 32bit and 64bit machines, with realtime preempt kernel, and without. When I test with the simplest process, the timing sounds as if the scheduler is drunk: (define (simp reps rate dur low hi) (process repeat reps do (send "mp:midi" :key (between low hi) :dur dur) (wait rate))) (sprout (simp 100 0.25 0.125 64 72)) I have no idea why this is happening, but I would like to find out. For that I would have to know if the problem is with the scheduler, or with the midi interface of Juce. If it would be Juce, I could file a bug report. Could somebody help me figure this out? For all my other midi programs, the midi timing is fine, so I doubt there is something fundamentally wrong with my system. But I would like to ask if there are any other people on this mailing list, which run CM3 successfully on Linux. Just to be sure it can be done :-) A few things to note: When I start Grace I get these warnings: Warning. Cannot connect jack output port 2: "alsa_pcm:Midi-Through/midi_playback_1". Warning. Cannot connect jack output port 3: "alsa_pcm:MT4/midi_playback_1". Warning. Cannot connect jack output port 4: "alsa_pcm:MT4/midi_playback_2". Warning. Cannot connect jack output port 5: "alsa_pcm:MT4/midi_playback_3". Warning. Cannot connect jack output port 6: "alsa_pcm:MT4/midi_playback_4". Warning. Cannot connect jack output port 7: "alsa_pcm:MT4/midi_playback_5". Warning. Cannot connect jack input port 2: "alsa_pcm:Midi-Through/midi_capture_1". Warning. Cannot connect jack input port 3: "alsa_pcm:MT4/midi_capture_1". Warning. Cannot connect jack input port 4: "alsa_pcm:MT4/midi_capture_2". Warning. Cannot connect jack input port 5: "alsa_pcm:MT4/midi_capture_3". In Grace I get a warning: Warning: Audio Manager: No such file or directory But sndlib is connected fine to the system audio outputs in JACK. I still have to connect Juce's midi port manually after starting Grace. Selecting a port from the menu does not make the connection. Thanks for your help, Lieven Moors P.S. I'm using the latest revision of CM3 from svn, and a quite recent sndlib (not the last, but one before that). P.S. It would be nice if Grace would support copy/paste with the x clipboard :-) From taube at uiuc.edu Mon Aug 10 07:26:57 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Mon, 10 Aug 2009 09:26:57 -0500 Subject: [CM] CM3 woes In-Reply-To: <4A802A41.3070402@gmail.com> References: <4A802A41.3070402@gmail.com> Message-ID: <6F9DFC9A-9343-46C0-AC75-367BC16C0605@uiuc.edu> as far as i remember we fixed your drift problem awhile back, was this not the case? I cant help with linux audio issues, whatever issues are there are with the juce support of linux or alsa itself. t On Aug 10, 2009, at 9:10 AM, lieven moors wrote: > Hi, > > I would like to report again that CM3 is still completely useless > to me, due to problems with midi timing. I'm working on Linux (Ubuntu > Studio), > and I've tried a lot in order to localize the problem on my 32bit and > 64bit machines, > with realtime preempt kernel, and without. > > When I test with the simplest process, the timing sounds as if the > scheduler is drunk: > > (define (simp reps rate dur low hi) > (process repeat reps > do > (send "mp:midi" :key (between low hi) :dur dur) > (wait rate))) > > (sprout (simp 100 0.25 0.125 64 72)) > > > I have no idea why this is happening, but I would like to find out. > For that I would have to know if the problem is with the scheduler, > or with the midi interface of Juce. If it would be Juce, I could > file a > bug report. > Could somebody help me figure this out? > > For all my other midi programs, the midi timing is fine, so I doubt > there > is something fundamentally wrong with my system. > But I would like to ask if there are any other people on this > mailing list, > which run CM3 successfully on Linux. Just to be sure it can be > done :-) > > A few things to note: > > When I start Grace I get these warnings: > > Warning. Cannot connect jack output port 2: > "alsa_pcm:Midi-Through/midi_playback_1". > Warning. Cannot connect jack output port 3: > "alsa_pcm:MT4/midi_playback_1". > Warning. Cannot connect jack output port 4: > "alsa_pcm:MT4/midi_playback_2". > Warning. Cannot connect jack output port 5: > "alsa_pcm:MT4/midi_playback_3". > Warning. Cannot connect jack output port 6: > "alsa_pcm:MT4/midi_playback_4". > Warning. Cannot connect jack output port 7: > "alsa_pcm:MT4/midi_playback_5". > Warning. Cannot connect jack input port 2: > "alsa_pcm:Midi-Through/midi_capture_1". > Warning. Cannot connect jack input port 3: > "alsa_pcm:MT4/midi_capture_1". > Warning. Cannot connect jack input port 4: > "alsa_pcm:MT4/midi_capture_2". > Warning. Cannot connect jack input port 5: > "alsa_pcm:MT4/midi_capture_3". > > In Grace I get a warning: > > Warning: Audio Manager: No such file or directory > > But sndlib is connected fine to the system audio outputs in JACK. > I still have to connect Juce's midi port manually after starting > Grace. > Selecting a port from the menu does not make the connection. > > Thanks for your help, > > Lieven Moors > > > P.S. I'm using the latest revision of CM3 from svn, and a quite recent > sndlib (not the last, but one before that). > P.S. It would be nice if Grace would support copy/paste with the x > clipboard :-) > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Mon Aug 10 09:11:41 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Mon, 10 Aug 2009 11:11:41 -0500 Subject: [CM] CM3 woes In-Reply-To: <4A803F66.7070107@gmail.com> References: <4A802A41.3070402@gmail.com> <6F9DFC9A-9343-46C0-AC75-367BC16C0605@uiuc.edu> <4A803F66.7070107@gmail.com> Message-ID: <64251398-E47F-468F-85FC-41A7EB2F4A79@uiuc.edu> am i confusing you with someone else? he ran a 20 minute regression test and reported that it was rock solid!! ill have to look through my old emails. the example sounds fine on osx, ill boot windows in a bit and try it there. (define (simp reps rate dur low hi) (process repeat reps do (send "mp:midi" :key (between low hi) :dur dur) (wait rate))) (sprout (simp 100 0.25 0.125 64 72)) On Aug 10, 2009, at 10:40 AM, lieven moors wrote: > No, they were never fixed, although I might have given you that > impression, > because writing to midi files seemed to work correctly. > I'll try to get some support from the Juce mailing list as well. From taube at uiuc.edu Mon Aug 10 10:05:58 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Mon, 10 Aug 2009 12:05:58 -0500 Subject: [CM] CM3 woes In-Reply-To: <4A804B8E.9070501@gmail.com> References: <4A802A41.3070402@gmail.com> <6F9DFC9A-9343-46C0-AC75-367BC16C0605@uiuc.edu> <4A803F66.7070107@gmail.com> <64251398-E47F-468F-85FC-41A7EB2F4A79@uiuc.edu> <4A804B8E.9070501@gmail.com> Message-ID: <50CC4A95-9139-4B84-9913-E5C0ED883463@uiuc.edu> >> the example sounds fine on osx, ill boot windows in a bit and try >> it there. it also sounds fine running an emulated windows with two voices each rhythm .125 !! so i dont know, the two platforms i can test on seem pretty good. sorry to punt but i dont know what to do about linux, it does seem like the issues are juce and/or alsa related. i wish juce would switch to jack! From lievenmoors at gmail.com Mon Aug 10 10:19:51 2009 From: lievenmoors at gmail.com (lieven moors) Date: Mon, 10 Aug 2009 19:19:51 +0200 Subject: [CM] CM3 woes In-Reply-To: <50CC4A95-9139-4B84-9913-E5C0ED883463@uiuc.edu> References: <4A802A41.3070402@gmail.com> <6F9DFC9A-9343-46C0-AC75-367BC16C0605@uiuc.edu> <4A803F66.7070107@gmail.com> <64251398-E47F-468F-85FC-41A7EB2F4A79@uiuc.edu> <4A804B8E.9070501@gmail.com> <50CC4A95-9139-4B84-9913-E5C0ED883463@uiuc.edu> Message-ID: <4A8056B7.7020601@gmail.com> Heinrich Taube wrote: >>> the example sounds fine on osx, ill boot windows in a bit and try it >>> there. > > > it also sounds fine running an emulated windows with two voices each > rhythm .125 !! > > so i dont know, the two platforms i can test on seem pretty good. > sorry to punt but i dont know what to do about linux, it does seem > like the issues are juce and/or alsa related. i wish juce would switch > to jack! > > Yes that would be nice, although ALSA midi has always worked well for me... Thanks for your help, Lieven From taube at uiuc.edu Mon Aug 10 10:24:02 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Mon, 10 Aug 2009 12:24:02 -0500 Subject: [CM] CM3 woes In-Reply-To: <4A8056B7.7020601@gmail.com> References: <4A802A41.3070402@gmail.com> <6F9DFC9A-9343-46C0-AC75-367BC16C0605@uiuc.edu> <4A803F66.7070107@gmail.com> <64251398-E47F-468F-85FC-41A7EB2F4A79@uiuc.edu> <4A804B8E.9070501@gmail.com> <50CC4A95-9139-4B84-9913-E5C0ED883463@uiuc.edu> <4A8056B7.7020601@gmail.com> Message-ID: <021BE260-7065-48F6-963D-7B0FEBB18947@uiuc.edu> i think you have two issues, one is the just audio support and then possibly a thread timing issue. but the scheduler per se seems to be fine (on osx and windows) ill try to resurrect a linux emulator and see if i can make sound (i gave up last time) On Aug 10, 2009, at 12:19 PM, lieven moors wrote: > Heinrich Taube wrote: >>>> the example sounds fine on osx, ill boot windows in a bit and try >>>> it there. >> >> >> it also sounds fine running an emulated windows with two voices >> each rhythm .125 !! >> >> so i dont know, the two platforms i can test on seem pretty good. >> sorry to punt but i dont know what to do about linux, it does seem >> like the issues are juce and/or alsa related. i wish juce would >> switch to jack! >> >> > Yes that would be nice, although ALSA midi has always worked well > for me... > Thanks for your help, > > Lieven > > From ja.lira0 at gmail.com Mon Aug 10 14:12:06 2009 From: ja.lira0 at gmail.com (James) Date: Mon, 10 Aug 2009 17:12:06 -0400 Subject: [CM] FFTs in Sound Message-ID: In snd, is it possible to display the spectral components of an FFT analysis as a text list of frequencies and amplitude in hertz? I'm trying to figure out how to do analysis-resynthesis and what I have in mind is to pass the frequency data as an array to a bank of oscillators in another program. Any help would be appreciated. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From taube at uiuc.edu Mon Aug 10 14:34:55 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Mon, 10 Aug 2009 16:34:55 -0500 Subject: [CM] CM3 linux threads In-Reply-To: <4A8056B7.7020601@gmail.com> References: <4A802A41.3070402@gmail.com> <6F9DFC9A-9343-46C0-AC75-367BC16C0605@uiuc.edu> <4A803F66.7070107@gmail.com> <64251398-E47F-468F-85FC-41A7EB2F4A79@uiuc.edu> <4A804B8E.9070501@gmail.com> <50CC4A95-9139-4B84-9913-E5C0ED883463@uiuc.edu> <4A8056B7.7020601@gmail.com> Message-ID: <5D51B8C7-0760-4C30-B74A-7E7EE816405E@uiuc.edu> ive looked into this linux issue a bit today with the help of andrew burnson. i do indeed hear the "drift" on an (emulated) linux but i do'nt yet know the cause or the cure (if any). its not Grace's scheduler per se: even if i spool midi messages out without using the scheduler or processes whatsoever i get the drift . as far as the scheduler lloop goes im able to improve it a bit by not 'waiting' but its not a huge improvment. the problem seems more basic, but im not sure if its Grace, or juce, or what. increasing the process priority of the Grace app itself and/or its individual threads doesnt seem to help. note that even with the drift you can still write midi files fine and you can also work with clm audio files, its just the realtime midi as far as i can tell. ill keep poking at this but any fix will probably not be in the next release (today or tomorrow) > Heinrich Taube wrote: >>>> the example sounds fine on osx, ill boot windows in a bit and try >>>> it >>>> there. >> >> >> it also sounds fine running an emulated windows with two voices each >> rhythm .125 !! >> >> so i dont know, the two platforms i can test on seem pretty good. >> sorry to punt but i dont know what to do about linux, it does seem >> like the issues are juce and/or alsa related. i wish juce would >> switch >> to jack! >> >> > Yes that would be nice, although ALSA midi has always worked well > for me... > Thanks for your help, > > Lieven > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From bil at ccrma.Stanford.EDU Tue Aug 11 03:45:47 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Tue, 11 Aug 2009 03:45:47 -0700 Subject: [CM] FFTs in Sound In-Reply-To: References: Message-ID: <20090811104437.M14756@ccrma.Stanford.EDU> > is it possible to display the spectral components of an FFT analysis as a > text list of frequencies and amplitude perhaps the "peaks" function is what you want. (peaks) puts up a dialog, (peaks "fft.data") writes the data to fft.data. You need to have an fft displayed. From lievenmoors at gmail.com Tue Aug 11 04:57:21 2009 From: lievenmoors at gmail.com (lieven moors) Date: Tue, 11 Aug 2009 13:57:21 +0200 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> Message-ID: <4A815CA1.4010804@gmail.com> I think I might know what the problem is with Juce. I had a look at the Juce code myself, and it looks like sendMessageNow() is not calling the snd_seq_drain_output(). this is an excerpt from the ALSA API documentation: If the event is sent immediately without enqueued, the sender doesn't take care of queue and timestamp. As well as the case above, there is a function to set the direct delivery, snd_seq_ev_set_direct() . The program can be more simplified as follows: void direct_delivery(snd_seq_t *seq) { snd_seq_event_t ev; snd_seq_ev_clear (&ev); snd_seq_ev_set_source (&ev, port); snd_seq_ev_set_subs (&ev); snd_seq_ev_set_direct (&ev); ... // set event type, data, so on.. snd_seq_event_output (seq, &ev); snd_seq_drain_output (seq); } You should flush event soon after output event. Otherwise, the event is enqueued on output queue of ALSA library (not in the kernel!), and will be never processed until this queue becomes full. I sounds like this might be excactly what happens.... I wonder what you or Andrew think about this, because I'm not too sure about it. It seems almost too simple to be true. Heinrich Taube wrote: > andrew thank you soooo much for your effort. maybe i could post your > code to the juce linux group to see if they have any ideas? > > Begin forwarded message: > >> From: William Andrew Burnson >> Date: August 10, 2009 10:04:20 PM CDT >> To: taube at illinois.edu >> Subject: Linux/Midi Test >> >> I wrote a simple JUCE console program to just spit out midi messages >> to Timidity in a single thread. I got the same results as we saw >> earlier today. I didn't even put the thread to sleep--I just had it >> spin through the hi-res timer until the right time and then used >> sendMessageNow to fire the MIDI messages. It was just as jerky. >> >> This means there is nothing you can do about this without going to a >> deeper level such as writing your own interface to ALSA. Whatever >> JUCE is doing doesn't seem to be sufficient for any kind of time >> precision. >> >> I suppose there are two types of uses of MIDI: >> MIDI -> Soundfont -> Audio >> In this case, there should be no reason why somewhere you couldn't >> specify "future" midi messages into the ALSA/Timidity bridge and it >> would render them precisely where they needed to be in terms of >> sampled audio. >> >> MIDI -> External device >> In this case, you would want access to a SMTPE clock. >> >> I am not sure if the kernel will make a difference. In any case, we >> could try my test program on different kernels to see, but I'm >> guessing it's a JUCE issue. > > From taube at uiuc.edu Tue Aug 11 05:22:21 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Tue, 11 Aug 2009 07:22:21 -0500 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <4A815CA1.4010804@gmail.com> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> Message-ID: <2CC15E56-9A50-4436-8EC7-567DF3F89B2D@uiuc.edu> you might try adding that line to sendMessageNow() in cm/src/ juce_Amalgamated.cpp then remake grace and test your example again (audio on my linux emulator doesnt work at all so i cant test it myself today) On Aug 11, 2009, at 6:57 AM, lieven moors wrote: > I think I might know what the problem is with Juce. I had a look at > the > Juce code myself, > and it looks like sendMessageNow() is not calling the > snd_seq_drain_output(). > this is an excerpt from the ALSA API documentation: > > If the event is sent immediately without enqueued, the sender > doesn't take care of queue and timestamp. As well as the case above, > there is a function to set the direct delivery, > snd_seq_ev_set_direct() > >. > The program can be more simplified as follows: > > void direct_delivery(snd_seq_t > *seq) > { > snd_seq_event_t > ev; > > snd_seq_ev_clear >(&ev); > snd_seq_ev_set_source >(&ev, port); > snd_seq_ev_set_subs >(&ev); > snd_seq_ev_set_direct >(&ev); > ... // set event type, data, so on.. > > snd_seq_event_output >(seq, &ev); > snd_seq_drain_output >(seq); > } > > You should flush event soon after output event. Otherwise, the > event > is enqueued on output queue of ALSA library (not in the kernel!), and > will be never processed until this queue becomes full. > > > I sounds like this might be excactly what happens.... > I wonder what you or Andrew think about this, because I'm not too sure > about it. > It seems almost too simple to be true. > > > > > > Heinrich Taube wrote: >> andrew thank you soooo much for your effort. maybe i could post your >> code to the juce linux group to see if they have any ideas? >> >> Begin forwarded message: >> >>> From: William Andrew Burnson >>> Date: August 10, 2009 10:04:20 PM CDT >>> To: taube at illinois.edu >>> Subject: Linux/Midi Test >>> >>> I wrote a simple JUCE console program to just spit out midi messages >>> to Timidity in a single thread. I got the same results as we saw >>> earlier today. I didn't even put the thread to sleep--I just had it >>> spin through the hi-res timer until the right time and then used >>> sendMessageNow to fire the MIDI messages. It was just as jerky. >>> >>> This means there is nothing you can do about this without going to a >>> deeper level such as writing your own interface to ALSA. Whatever >>> JUCE is doing doesn't seem to be sufficient for any kind of time >>> precision. >>> >>> I suppose there are two types of uses of MIDI: >>> MIDI -> Soundfont -> Audio >>> In this case, there should be no reason why somewhere you couldn't >>> specify "future" midi messages into the ALSA/Timidity bridge and it >>> would render them precisely where they needed to be in terms of >>> sampled audio. >>> >>> MIDI -> External device >>> In this case, you would want access to a SMTPE clock. >>> >>> I am not sure if the kernel will make a difference. In any case, we >>> could try my test program on different kernels to see, but I'm >>> guessing it's a JUCE issue. >> >> > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From lievenmoors at gmail.com Tue Aug 11 05:30:44 2009 From: lievenmoors at gmail.com (lieven moors) Date: Tue, 11 Aug 2009 14:30:44 +0200 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <2CC15E56-9A50-4436-8EC7-567DF3F89B2D@uiuc.edu> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> <2CC15E56-9A50-4436-8EC7-567DF3F89B2D@uiuc.edu> Message-ID: <4A816474.5030900@gmail.com> I just did, but it doesn't seem to help. I'll have to do some more testing... Heinrich Taube wrote: > you might try adding that line to sendMessageNow() in > cm/src/juce_Amalgamated.cpp then remake grace and test your example > again (audio on my linux emulator doesnt work at all so i cant test it > myself today) > > On Aug 11, 2009, at 6:57 AM, lieven moors wrote: > >> I think I might know what the problem is with Juce. I had a look at the >> Juce code myself, >> and it looks like sendMessageNow() is not calling the >> snd_seq_drain_output(). >> this is an excerpt from the ALSA API documentation: >> >> If the event is sent immediately without enqueued, the sender >> doesn't take care of queue and timestamp. As well as the case above, >> there is a function to set the direct delivery, >> snd_seq_ev_set_direct() >> . >> >> The program can be more simplified as follows: >> >> void direct_delivery(snd_seq_t >> >> *seq) >> { >> snd_seq_event_t >> >> ev; >> >> snd_seq_ev_clear >> (&ev); >> >> snd_seq_ev_set_source >> (&ev, >> port); >> snd_seq_ev_set_subs >> (&ev); >> >> snd_seq_ev_set_direct >> (&ev); >> >> ... // set event type, data, so on.. >> >> snd_seq_event_output >> (seq, >> &ev); >> snd_seq_drain_output >> (seq); >> >> } >> >> You should flush event soon after output event. Otherwise, the event >> is enqueued on output queue of ALSA library (not in the kernel!), and >> will be never processed until this queue becomes full. >> >> >> I sounds like this might be excactly what happens.... >> I wonder what you or Andrew think about this, because I'm not too sure >> about it. >> It seems almost too simple to be true. >> >> >> >> >> >> Heinrich Taube wrote: >>> andrew thank you soooo much for your effort. maybe i could post your >>> code to the juce linux group to see if they have any ideas? >>> >>> Begin forwarded message: >>> >>>> From: William Andrew Burnson >>>> Date: August 10, 2009 10:04:20 PM CDT >>>> To: taube at illinois.edu >>>> Subject: Linux/Midi Test >>>> >>>> I wrote a simple JUCE console program to just spit out midi messages >>>> to Timidity in a single thread. I got the same results as we saw >>>> earlier today. I didn't even put the thread to sleep--I just had it >>>> spin through the hi-res timer until the right time and then used >>>> sendMessageNow to fire the MIDI messages. It was just as jerky. >>>> >>>> This means there is nothing you can do about this without going to a >>>> deeper level such as writing your own interface to ALSA. Whatever >>>> JUCE is doing doesn't seem to be sufficient for any kind of time >>>> precision. >>>> >>>> I suppose there are two types of uses of MIDI: >>>> MIDI -> Soundfont -> Audio >>>> In this case, there should be no reason why somewhere you couldn't >>>> specify "future" midi messages into the ALSA/Timidity bridge and it >>>> would render them precisely where they needed to be in terms of >>>> sampled audio. >>>> >>>> MIDI -> External device >>>> In this case, you would want access to a SMTPE clock. >>>> >>>> I am not sure if the kernel will make a difference. In any case, we >>>> could try my test program on different kernels to see, but I'm >>>> guessing it's a JUCE issue. >>> >>> >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > > From k.s.matheussen at notam02.no Tue Aug 11 06:43:31 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST) Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <4A815CA1.4010804@gmail.com> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> Message-ID: On Tue, 11 Aug 2009, lieven moors wrote: > I think I might know what the problem is with Juce. I had a look at the > Juce code myself, > and it looks like sendMessageNow() is not calling the > snd_seq_drain_output(). For what its worth, the one time I've written code which sends midi via alsa, the code calls snd_seq_drain_output as last operation. I don't remember what I did back then, but this could definitely be the problem. It sounds likely, at least. static void alsaseq_PutMidi( struct MidiLink *midilink, uint32_t msg ) { unsigned int d3=(msg>>8)&0xff; unsigned int d2=(msg>>16)&0xff; unsigned int d1=(msg>>24)&0xff; unsigned char buffer[3]={d1,d2,d3}; snd_seq_event_t ev; snd_midi_event_t *midi_ev; snd_midi_event_new( 10, &midi_ev ); snd_seq_ev_clear( &ev ); snd_midi_event_encode(midi_ev, buffer, 3, &ev); snd_midi_event_free( midi_ev ); snd_seq_ev_set_source(&ev,midilink->port); snd_seq_ev_set_subs(&ev); snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); snd_seq_event_output(radium_seq, &ev); snd_seq_drain_output(radium_seq); } From lievenmoors at gmail.com Tue Aug 11 07:05:11 2009 From: lievenmoors at gmail.com (lieven moors) Date: Tue, 11 Aug 2009 16:05:11 +0200 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> Message-ID: <4A817A97.6000900@gmail.com> Kjetil S. Matheussen wrote: > > > On Tue, 11 Aug 2009, lieven moors wrote: > >> I think I might know what the problem is with Juce. I had a look at the >> Juce code myself, >> and it looks like sendMessageNow() is not calling the >> snd_seq_drain_output(). > > For what its worth, the one time I've written code which sends > midi via alsa, the code calls snd_seq_drain_output as last > operation. I don't remember what I did back then, but this > could definitely be the problem. It sounds likely, at least. > > > static void alsaseq_PutMidi( > struct MidiLink *midilink, > uint32_t msg > ) > { > unsigned int d3=(msg>>8)&0xff; > unsigned int d2=(msg>>16)&0xff; > unsigned int d1=(msg>>24)&0xff; > > unsigned char buffer[3]={d1,d2,d3}; > snd_seq_event_t ev; > snd_midi_event_t *midi_ev; > snd_midi_event_new( 10, &midi_ev ); > > snd_seq_ev_clear( &ev ); > snd_midi_event_encode(midi_ev, > buffer, > 3, > &ev); > snd_midi_event_free( midi_ev ); > > snd_seq_ev_set_source(&ev,midilink->port); > snd_seq_ev_set_subs(&ev); > > snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); > > snd_seq_event_output(radium_seq, &ev); > > snd_seq_drain_output(radium_seq); > > } > > But the code in Juce calls snd_seq_event_output_direct() instead of snd_seq_event_output() and doesn't call snd_seq_drain_output(). I've tried replacing snd_seq_event_output_direct() with snd_seq_event_output() snd_seq_drain_output() but timing still doesn't sound right. I can't say for sure if it sounds different So it is not that simple. But I think there is a problem with how the buffers are used. From lievenmoors at gmail.com Tue Aug 11 10:09:55 2009 From: lievenmoors at gmail.com (lieven moors) Date: Tue, 11 Aug 2009 19:09:55 +0200 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <20090811113334.BXC36005@expms2.cites.uiuc.edu> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> <20090811113334.BXC36005@expms2.cites.uiuc.edu> Message-ID: <4A81A5E3.40508@gmail.com> I tried the test program with a suprising result. The timing sounds rock solid, with normal permissions, and with a duration of 62.5 ms. P.S. When I selected realtime permission, the process was killed by das_watchdog, and I heard nothing. (das_watchdog guards for realtime processes that block the system) William Andrew Burnson wrote: > Here is my test program to play back notes in a single JUCE thread to help detect jitter: > http://williamburnson.com/midi-test.tar.gz > > To use it, follow INSTRUCTIONS (basically, drop juce_amalgamated.cpp/h into the folder and type make) > > I tried using snd_seq_drain_output and I didn't notice any difference... > > ---- Original message ---- > >> Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST) >> From: "Kjetil S. Matheussen" >> Subject: Re: [CM] Fwd: Linux/Midi Test >> To: lieven moors >> Cc: Heinrich Taube , cmdist at ccrma.Stanford.EDU, Andrew Burnson >> >> >> >> On Tue, 11 Aug 2009, lieven moors wrote: >> >> >>> I think I might know what the problem is with Juce. I had a look at the >>> Juce code myself, >>> and it looks like sendMessageNow() is not calling the >>> snd_seq_drain_output(). >>> >> For what its worth, the one time I've written code which sends >> midi via alsa, the code calls snd_seq_drain_output as last >> operation. I don't remember what I did back then, but this >> could definitely be the problem. It sounds likely, at least. >> >> >> static void alsaseq_PutMidi( >> struct MidiLink *midilink, >> uint32_t msg >> ) >> { >> unsigned int d3=(msg>>8)&0xff; >> unsigned int d2=(msg>>16)&0xff; >> unsigned int d1=(msg>>24)&0xff; >> >> unsigned char buffer[3]={d1,d2,d3}; >> snd_seq_event_t ev; >> snd_midi_event_t *midi_ev; >> snd_midi_event_new( 10, &midi_ev ); >> >> snd_seq_ev_clear( &ev ); >> snd_midi_event_encode(midi_ev, >> buffer, >> 3, >> &ev); >> snd_midi_event_free( midi_ev ); >> >> snd_seq_ev_set_source(&ev,midilink->port); >> snd_seq_ev_set_subs(&ev); >> >> snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); >> >> snd_seq_event_output(radium_seq, &ev); >> >> snd_seq_drain_output(radium_seq); >> >> } >> >> > > From lievenmoors at gmail.com Tue Aug 11 10:21:05 2009 From: lievenmoors at gmail.com (lieven moors) Date: Tue, 11 Aug 2009 19:21:05 +0200 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <4A81A5E3.40508@gmail.com> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> <20090811113334.BXC36005@expms2.cites.uiuc.edu> <4A81A5E3.40508@gmail.com> Message-ID: <4A81A881.1030204@gmail.com> And another thing, when selecting high priority, I do hear sound initially, but it is totally fucked up (timingwise), and the process gets killed finally by the watchdog. lieven moors wrote: > I tried the test program with a suprising result. > The timing sounds rock solid, with normal permissions, and with a > duration of 62.5 ms. > > P.S. > When I selected realtime permission, the process was killed by > das_watchdog, and I heard nothing. > (das_watchdog guards for realtime processes that block the system) > > William Andrew Burnson wrote: >> Here is my test program to play back notes in a single JUCE thread to >> help detect jitter: >> http://williamburnson.com/midi-test.tar.gz >> >> To use it, follow INSTRUCTIONS (basically, drop >> juce_amalgamated.cpp/h into the folder and type make) >> >> I tried using snd_seq_drain_output and I didn't notice any difference... >> >> ---- Original message ---- >> >>> Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST) >>> From: "Kjetil S. Matheussen" Subject: >>> Re: [CM] Fwd: Linux/Midi Test To: lieven moors >>> Cc: Heinrich Taube , cmdist at ccrma.Stanford.EDU, >>> Andrew Burnson >>> >>> >>> >>> On Tue, 11 Aug 2009, lieven moors wrote: >>> >>> >>>> I think I might know what the problem is with Juce. I had a look at >>>> the >>>> Juce code myself, >>>> and it looks like sendMessageNow() is not calling the >>>> snd_seq_drain_output(). >>>> >>> For what its worth, the one time I've written code which sends >>> midi via alsa, the code calls snd_seq_drain_output as last >>> operation. I don't remember what I did back then, but this >>> could definitely be the problem. It sounds likely, at least. >>> >>> >>> static void alsaseq_PutMidi( >>> struct MidiLink *midilink, >>> uint32_t msg >>> ) >>> { >>> unsigned int d3=(msg>>8)&0xff; >>> unsigned int d2=(msg>>16)&0xff; >>> unsigned int d1=(msg>>24)&0xff; >>> >>> unsigned char buffer[3]={d1,d2,d3}; >>> snd_seq_event_t ev; >>> snd_midi_event_t *midi_ev; >>> snd_midi_event_new( 10, &midi_ev ); >>> >>> snd_seq_ev_clear( &ev ); >>> snd_midi_event_encode(midi_ev, >>> buffer, >>> 3, >>> &ev); >>> snd_midi_event_free( midi_ev ); >>> >>> snd_seq_ev_set_source(&ev,midilink->port); >>> snd_seq_ev_set_subs(&ev); >>> >>> snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); >>> >>> snd_seq_event_output(radium_seq, &ev); >>> >>> snd_seq_drain_output(radium_seq); >>> >>> } >>> >>> >> >> > > From k.s.matheussen at notam02.no Tue Aug 11 10:43:30 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Tue, 11 Aug 2009 19:43:30 +0200 (CEST) Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <4A81A881.1030204@gmail.com> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> <20090811113334.BXC36005@expms2.cites.uiuc.edu> <4A81A5E3.40508@gmail.com> <4A81A881.1030204@gmail.com> Message-ID: That's weird. Firstly, it's strange that you get bad timing when setting high priority (is that sched_fifo or sched_rr?). Secondly, das_watchdog should never kill any process. If the machine hangs, it just temporarily turns off realtime priority for most processes to see if that helps. And I should know this since I actually wrote das_watchdog. ;-) On Tue, 11 Aug 2009, lieven moors wrote: > And another thing, when selecting high priority, > I do hear sound initially, but it is totally fucked up (timingwise), and the > process gets killed > finally by the watchdog. > > lieven moors wrote: >> I tried the test program with a suprising result. >> The timing sounds rock solid, with normal permissions, and with a duration >> of 62.5 ms. >> >> P.S. >> When I selected realtime permission, the process was killed by >> das_watchdog, and I heard nothing. >> (das_watchdog guards for realtime processes that block the system) >> >> William Andrew Burnson wrote: >>> Here is my test program to play back notes in a single JUCE thread to help >>> detect jitter: >>> http://williamburnson.com/midi-test.tar.gz >>> >>> To use it, follow INSTRUCTIONS (basically, drop juce_amalgamated.cpp/h >>> into the folder and type make) >>> >>> I tried using snd_seq_drain_output and I didn't notice any difference... >>> >>> ---- Original message ---- >>> >>>> Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST) >>>> From: "Kjetil S. Matheussen" Subject: Re: >>>> [CM] Fwd: Linux/Midi Test To: lieven moors >>>> Cc: Heinrich Taube , cmdist at ccrma.Stanford.EDU, Andrew >>>> Burnson >>>> >>>> >>>> >>>> On Tue, 11 Aug 2009, lieven moors wrote: >>>> >>>> >>>>> I think I might know what the problem is with Juce. I had a look at the >>>>> Juce code myself, >>>>> and it looks like sendMessageNow() is not calling the >>>>> snd_seq_drain_output(). >>>>> >>>> For what its worth, the one time I've written code which sends >>>> midi via alsa, the code calls snd_seq_drain_output as last >>>> operation. I don't remember what I did back then, but this >>>> could definitely be the problem. It sounds likely, at least. >>>> >>>> >>>> static void alsaseq_PutMidi( >>>> struct MidiLink *midilink, >>>> uint32_t msg >>>> ) >>>> { >>>> unsigned int d3=(msg>>8)&0xff; >>>> unsigned int d2=(msg>>16)&0xff; >>>> unsigned int d1=(msg>>24)&0xff; >>>> >>>> unsigned char buffer[3]={d1,d2,d3}; >>>> snd_seq_event_t ev; >>>> snd_midi_event_t *midi_ev; >>>> snd_midi_event_new( 10, &midi_ev ); >>>> >>>> snd_seq_ev_clear( &ev ); >>>> snd_midi_event_encode(midi_ev, >>>> buffer, >>>> 3, >>>> &ev); >>>> snd_midi_event_free( midi_ev ); >>>> >>>> snd_seq_ev_set_source(&ev,midilink->port); >>>> snd_seq_ev_set_subs(&ev); >>>> >>>> snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); >>>> >>>> snd_seq_event_output(radium_seq, &ev); >>>> >>>> snd_seq_drain_output(radium_seq); >>>> >>>> } >>>> >>>> >>> >>> >> >> > > From taube at uiuc.edu Tue Aug 11 10:51:26 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Tue, 11 Aug 2009 12:51:26 -0500 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <4A81A5E3.40508@gmail.com> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> <20090811113334.BXC36005@expms2.cites.uiuc.edu> <4A81A5E3.40508@gmail.com> Message-ID: <93CA729F-4927-40EE-B2A7-A34826D3EA8C@uiuc.edu> well then im back to square zero. your result would indicate that the problem is local to my (grace) process(es), but andrew gets the drift without grace at all. or maybe what he hears isnt the same as what you are reporting On Aug 11, 2009, at 12:09 PM, lieven moors wrote: > I tried the test program with a suprising result. > The timing sounds rock solid, with normal permissions, and with a > duration of 62.5 ms. > > P.S. > When I selected realtime permission, the process was killed by > das_watchdog, and I heard nothing. > (das_watchdog guards for realtime processes that block the system) > From lievenmoors at gmail.com Tue Aug 11 11:04:30 2009 From: lievenmoors at gmail.com (lieven moors) Date: Tue, 11 Aug 2009 20:04:30 +0200 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> <20090811113334.BXC36005@expms2.cites.uiuc.edu> <4A81A5E3.40508@gmail.com> <4A81A881.1030204@gmail.com> Message-ID: <4A81B2AE.2030207@gmail.com> I'm sorry to confuse you, but when I said that timing sounded rock solid, I had forgotten that I had edited the juce_amalgamated.cpp file. When I reverted to the original version, the timing sounded worse again. I had edited the sendMessageNow funtion: changed snd_seq_event_output_direct(seqHandle, &event); into snd_seq_event_output (seqHandle, &event); snd_seq_drain_output (seqHandle); Could somebody check this? Kjetil S. Matheussen wrote: > > That's weird. > > Firstly, it's strange that you get bad timing when setting > high priority (is that sched_fifo or sched_rr?). > > Secondly, das_watchdog should never kill any process. If > the machine hangs, it just temporarily > turns off realtime priority for most processes to see > if that helps. > And I should know this since I actually wrote das_watchdog. ;-) > > > > On Tue, 11 Aug 2009, lieven moors wrote: > >> And another thing, when selecting high priority, >> I do hear sound initially, but it is totally fucked up (timingwise), >> and the process gets killed >> finally by the watchdog. >> >> lieven moors wrote: >>> I tried the test program with a suprising result. >>> The timing sounds rock solid, with normal permissions, and with a >>> duration of 62.5 ms. >>> >>> P.S. >>> When I selected realtime permission, the process was killed by >>> das_watchdog, and I heard nothing. >>> (das_watchdog guards for realtime processes that block the system) >>> >>> William Andrew Burnson wrote: >>>> Here is my test program to play back notes in a single JUCE thread >>>> to help detect jitter: >>>> http://williamburnson.com/midi-test.tar.gz >>>> >>>> To use it, follow INSTRUCTIONS (basically, drop >>>> juce_amalgamated.cpp/h into the folder and type make) >>>> >>>> I tried using snd_seq_drain_output and I didn't notice any >>>> difference... >>>> >>>> ---- Original message ---- >>>> >>>>> Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST) >>>>> From: "Kjetil S. Matheussen" Subject: >>>>> Re: [CM] Fwd: Linux/Midi Test To: lieven moors >>>>> >>>>> Cc: Heinrich Taube , cmdist at ccrma.Stanford.EDU, >>>>> Andrew Burnson >>>>> >>>>> >>>>> >>>>> On Tue, 11 Aug 2009, lieven moors wrote: >>>>> >>>>> >>>>>> I think I might know what the problem is with Juce. I had a look >>>>>> at the >>>>>> Juce code myself, >>>>>> and it looks like sendMessageNow() is not calling the >>>>>> snd_seq_drain_output(). >>>>>> >>>>> For what its worth, the one time I've written code which sends >>>>> midi via alsa, the code calls snd_seq_drain_output as last >>>>> operation. I don't remember what I did back then, but this >>>>> could definitely be the problem. It sounds likely, at least. >>>>> >>>>> >>>>> static void alsaseq_PutMidi( >>>>> struct MidiLink *midilink, >>>>> uint32_t msg >>>>> ) >>>>> { >>>>> unsigned int d3=(msg>>8)&0xff; >>>>> unsigned int d2=(msg>>16)&0xff; >>>>> unsigned int d1=(msg>>24)&0xff; >>>>> >>>>> unsigned char buffer[3]={d1,d2,d3}; >>>>> snd_seq_event_t ev; >>>>> snd_midi_event_t *midi_ev; >>>>> snd_midi_event_new( 10, &midi_ev ); >>>>> >>>>> snd_seq_ev_clear( &ev ); >>>>> snd_midi_event_encode(midi_ev, >>>>> buffer, >>>>> 3, >>>>> &ev); >>>>> snd_midi_event_free( midi_ev ); >>>>> >>>>> snd_seq_ev_set_source(&ev,midilink->port); >>>>> snd_seq_ev_set_subs(&ev); >>>>> >>>>> snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); >>>>> >>>>> snd_seq_event_output(radium_seq, &ev); >>>>> >>>>> snd_seq_drain_output(radium_seq); >>>>> >>>>> } >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From burnson2 at illinois.edu Tue Aug 11 09:33:34 2009 From: burnson2 at illinois.edu (William Andrew Burnson) Date: Tue, 11 Aug 2009 11:33:34 -0500 (CDT) Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> Message-ID: <20090811113334.BXC36005@expms2.cites.uiuc.edu> Here is my test program to play back notes in a single JUCE thread to help detect jitter: http://williamburnson.com/midi-test.tar.gz To use it, follow INSTRUCTIONS (basically, drop juce_amalgamated.cpp/h into the folder and type make) I tried using snd_seq_drain_output and I didn't notice any difference... ---- Original message ---- >Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST) >From: "Kjetil S. Matheussen" >Subject: Re: [CM] Fwd: Linux/Midi Test >To: lieven moors >Cc: Heinrich Taube , cmdist at ccrma.Stanford.EDU, Andrew Burnson > > > >On Tue, 11 Aug 2009, lieven moors wrote: > >> I think I might know what the problem is with Juce. I had a look at the >> Juce code myself, >> and it looks like sendMessageNow() is not calling the >> snd_seq_drain_output(). > >For what its worth, the one time I've written code which sends >midi via alsa, the code calls snd_seq_drain_output as last >operation. I don't remember what I did back then, but this >could definitely be the problem. It sounds likely, at least. > > >static void alsaseq_PutMidi( > struct MidiLink *midilink, > uint32_t msg > ) >{ > unsigned int d3=(msg>>8)&0xff; > unsigned int d2=(msg>>16)&0xff; > unsigned int d1=(msg>>24)&0xff; > > unsigned char buffer[3]={d1,d2,d3}; > snd_seq_event_t ev; > snd_midi_event_t *midi_ev; > snd_midi_event_new( 10, &midi_ev ); > > snd_seq_ev_clear( &ev ); > snd_midi_event_encode(midi_ev, > buffer, > 3, > &ev); > snd_midi_event_free( midi_ev ); > > snd_seq_ev_set_source(&ev,midilink->port); > snd_seq_ev_set_subs(&ev); > > snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); > > snd_seq_event_output(radium_seq, &ev); > > snd_seq_drain_output(radium_seq); > >} > From burnson2 at illinois.edu Tue Aug 11 11:27:44 2009 From: burnson2 at illinois.edu (William Andrew Burnson) Date: Tue, 11 Aug 2009 13:27:44 -0500 (CDT) Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <4A81B2AE.2030207@gmail.com> References: <20090810220420.BXB91514@expms2.cites.uiuc.edu> <33EF7345-39B9-42F5-836C-959A8123BBE0@uiuc.edu> <4A815CA1.4010804@gmail.com> <20090811113334.BXC36005@expms2.cites.uiuc.edu> <4A81A5E3.40508@gmail.com> <4A81A881.1030204@gmail.com> <4A81B2AE.2030207@gmail.com> Message-ID: <20090811132744.BXC45025@expms2.cites.uiuc.edu> I can confirm this, it does work! I'm using VirtualBox Ubuntu, and even still, swapping for those two lines does suddenly get rid of all jitter. It's rock solid as lieven says. I don't think process priority should be changed either as this isn't really a threading issue. I will post this on the JUCE forum to let Jules know. In the meantime, if it's possible Rick, then the best approach would be to use sendMessageNow for all MIDI out and hack line 46989 in juce_amalgamated.cpp and change from: snd_seq_event_output_direct(seqHandle, &event); to snd_seq_event_output (seqHandle, &event); snd_seq_drain_output (seqHandle); ---- Original message ---- >Date: Tue, 11 Aug 2009 20:04:30 +0200 >From: lieven moors >Subject: Re: [CM] Fwd: Linux/Midi Test >To: "Kjetil S. Matheussen" , Heinrich Taube >Cc: Andrew Burnson , cmdist at ccrma.stanford.edu > >I'm sorry to confuse you, but when I said that timing sounded rock solid, >I had forgotten that I had edited the juce_amalgamated.cpp file. >When I reverted to the original version, the timing sounded worse again. > >I had edited the sendMessageNow funtion: > >changed > > snd_seq_event_output_direct(seqHandle, &event); > >into > snd_seq_event_output (seqHandle, &event); > snd_seq_drain_output (seqHandle); > >Could somebody check this? > > >Kjetil S. Matheussen wrote: >> >> That's weird. >> >> Firstly, it's strange that you get bad timing when setting >> high priority (is that sched_fifo or sched_rr?). >> >> Secondly, das_watchdog should never kill any process. If >> the machine hangs, it just temporarily >> turns off realtime priority for most processes to see >> if that helps. >> And I should know this since I actually wrote das_watchdog. ;-) >> >> >> >> On Tue, 11 Aug 2009, lieven moors wrote: >> >>> And another thing, when selecting high priority, >>> I do hear sound initially, but it is totally fucked up (timingwise), >>> and the process gets killed >>> finally by the watchdog. >>> >>> lieven moors wrote: >>>> I tried the test program with a suprising result. >>>> The timing sounds rock solid, with normal permissions, and with a >>>> duration of 62.5 ms. >>>> >>>> P.S. >>>> When I selected realtime permission, the process was killed by >>>> das_watchdog, and I heard nothing. >>>> (das_watchdog guards for realtime processes that block the system) >>>> >>>> William Andrew Burnson wrote: >>>>> Here is my test program to play back notes in a single JUCE thread >>>>> to help detect jitter: >>>>> http://williamburnson.com/midi-test.tar.gz >>>>> >>>>> To use it, follow INSTRUCTIONS (basically, drop >>>>> juce_amalgamated.cpp/h into the folder and type make) >>>>> >>>>> I tried using snd_seq_drain_output and I didn't notice any >>>>> difference... >>>>> >>>>> ---- Original message ---- >>>>> >>>>>> Date: Tue, 11 Aug 2009 15:43:31 +0200 (CEST) >>>>>> From: "Kjetil S. Matheussen" Subject: >>>>>> Re: [CM] Fwd: Linux/Midi Test To: lieven moors >>>>>> >>>>>> Cc: Heinrich Taube , cmdist at ccrma.Stanford.EDU, >>>>>> Andrew Burnson >>>>>> >>>>>> >>>>>> >>>>>> On Tue, 11 Aug 2009, lieven moors wrote: >>>>>> >>>>>> >>>>>>> I think I might know what the problem is with Juce. I had a look >>>>>>> at the >>>>>>> Juce code myself, >>>>>>> and it looks like sendMessageNow() is not calling the >>>>>>> snd_seq_drain_output(). >>>>>>> >>>>>> For what its worth, the one time I've written code which sends >>>>>> midi via alsa, the code calls snd_seq_drain_output as last >>>>>> operation. I don't remember what I did back then, but this >>>>>> could definitely be the problem. It sounds likely, at least. >>>>>> >>>>>> >>>>>> static void alsaseq_PutMidi( >>>>>> struct MidiLink *midilink, >>>>>> uint32_t msg >>>>>> ) >>>>>> { >>>>>> unsigned int d3=(msg>>8)&0xff; >>>>>> unsigned int d2=(msg>>16)&0xff; >>>>>> unsigned int d1=(msg>>24)&0xff; >>>>>> >>>>>> unsigned char buffer[3]={d1,d2,d3}; >>>>>> snd_seq_event_t ev; >>>>>> snd_midi_event_t *midi_ev; >>>>>> snd_midi_event_new( 10, &midi_ev ); >>>>>> >>>>>> snd_seq_ev_clear( &ev ); >>>>>> snd_midi_event_encode(midi_ev, >>>>>> buffer, >>>>>> 3, >>>>>> &ev); >>>>>> snd_midi_event_free( midi_ev ); >>>>>> >>>>>> snd_seq_ev_set_source(&ev,midilink->port); >>>>>> snd_seq_ev_set_subs(&ev); >>>>>> >>>>>> snd_seq_ev_schedule_tick( &ev, radium_queue, 1, 1); >>>>>> >>>>>> snd_seq_event_output(radium_seq, &ev); >>>>>> >>>>>> snd_seq_drain_output(radium_seq); >>>>>> >>>>>> } >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > From taube at uiuc.edu Tue Aug 11 12:10:16 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Tue, 11 Aug 2009 14:10:16 -0500 Subject: [CM] Announce: Grace 3.3.0 with Fomus (beta1) Message-ID: <09C9F7D5-E06A-4FD8-98A4-91A1C0512C73@uiuc.edu> Finally! A binary (beta) release of Grace built with c++ Fomus and s7/ SndLib is available for download. Fomus is a music manuscripting package by David Psenicka that transforms symbolic score information into fully manuscripted output using Lilypond or Sibelius/Finale via MusicXML. right now we've got a binary install for osx/10.5; hopefully a windows installer will be available at some point soon. on linux you compile from sources (boost, fomus, grace) heres the (temporary) link to the beta for osx (all one line): http://camil.music.uiuc.edu/Software/grace/downloads/grace-with-fomus-osx-beta1.zip the osx installer will put Grace in your /Applications folder and the Fomus runtime under /usr/local/. this is a beta release in anticipation of icmc and fall courses. its new, large and complex and so we are hoping you will help with general testing and feedback. i dont want to add any more features for this release but will do everything to make sure that what we have is working. You can configure your Fomus environment in Grace using the "Audio>Fomus" submenu. To learn about Fomus use the Help menu: "Help>Examples>Fomus Examples" has various manuscripting examples (try the last example that generates harmonic gesture. fomus does a beautiful fast output! ) "Help>Tutorials>Fomus" has a step by step walk-through. Documentation about sending fomus messages is in "Help>Manuals>Common Music" The easiest/cheapest way to work with Fomus is to install Lilypond (http://lilypond.org ) On the mac you only need to install the app bundle itself. (dont attemp to use it directly because it doesnt work as a stand alone...see the lilypond website for their information) here is their osx package link(all one line) http://download.linuxaudio.org/lilypond/binaries/darwin-x86/lilypond-2.12.2-1.darwin-x86.tar.bz2 From lievenmoors at gmail.com Tue Aug 11 12:41:03 2009 From: lievenmoors at gmail.com (lieven moors) Date: Tue, 11 Aug 2009 21:41:03 +0200 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: References: <4A81B92B.9050807@gmail.com> Message-ID: <4A81C94F.5030506@gmail.com> Ok I managed, apparently if you change to SCHED_OTHER, the only value you can use for the priority is 0, in order to set it. I thought I could use the 'nice' value... I changed the realtime thread of CM to SCHED_OTHER because I thought it might reveal a problem in Juce with realtime scheduling (I had terrible results when running the test program with realtime scheduling). But still no luck. Even with SCHED_OTHER, and with the changes to juce_amalgamated, CM doesn't sounds tight with a very simple process. Thanks for all your help today, and I'll have another stab at it later. Greetings Kjetil S. Matheussen wrote: > > > On Tue, 11 Aug 2009, lieven moors wrote: > >> It's seems that the only way I got a good timing, was by running the >> process >> in a normal, non realtime thread. I can change the realtime priority >> of the CM thread >> to 1 (lowest), but I cannot change it into a normal priority thread >> (I don't know how). >> Could you tell me what (and where) to change, so that the CM thread >> wouldn't use realtime priority? >> >> Or perhaps kjetil: do you know how to do that without recompiling CM? >> > > You can use the chrt command to get/set scheduling policy and priority. > > > For setting scheduling policy and priority in c, I use the following > function in das_watchdog: > > static int set_pid_priority(pid_t pid,int policy,int priority,char > *message,char *name){ > struct sched_param par={0}; > par.sched_priority=priority; > if((sched_setscheduler(pid,policy,&par)!=0)){ > print_error(stderr,message,pid,name,strerror(errno)); > return 0; > } > return 1; > } > > > > To set normal priority for a process, it can be called like this: > > set_pid_priority(pid,SCHED_OTHER,0,"Could not set pid %d (\"%s\") to > SCHED_OTHER (%s).\n","no name")) > > From k.s.matheussen at notam02.no Tue Aug 11 12:50:05 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Tue, 11 Aug 2009 21:50:05 +0200 (CEST) Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: <4A81C94F.5030506@gmail.com> References: <4A81B92B.9050807@gmail.com> <4A81C94F.5030506@gmail.com> Message-ID: To change the priority of a SCHED_OTHER program, you can use setpriority instead. The last argument for setpriority selects the nice priority, which goes from -20 to 19. -20 is highest priority, 19 the lowest. So to change the priority of the current process to highest possible non-realtime, you call setpriority(PRIO_PROCESS,0,-20) I think you can change the priority of a different process by setting the second argument of setpriority to a pid. On Tue, 11 Aug 2009, lieven moors wrote: > Ok I managed, apparently if you change to SCHED_OTHER, the only value you > can use for the priority is 0, in order to set it. I thought I could use the > 'nice' value... > > I changed the realtime thread of CM to SCHED_OTHER because I thought it might > reveal a problem > in Juce with realtime scheduling (I had terrible results when running the > test program with realtime scheduling). > But still no luck. Even with SCHED_OTHER, and with the changes to > juce_amalgamated, CM doesn't sounds tight > with a very simple process. > > Thanks for all your help today, and I'll have another stab at it later. > > Greetings > > > Kjetil S. Matheussen wrote: >> >> >> On Tue, 11 Aug 2009, lieven moors wrote: >> >>> It's seems that the only way I got a good timing, was by running the >>> process >>> in a normal, non realtime thread. I can change the realtime priority of >>> the CM thread >>> to 1 (lowest), but I cannot change it into a normal priority thread (I >>> don't know how). >>> Could you tell me what (and where) to change, so that the CM thread >>> wouldn't use realtime priority? >>> >>> Or perhaps kjetil: do you know how to do that without recompiling CM? >>> >> >> You can use the chrt command to get/set scheduling policy and priority. >> >> >> For setting scheduling policy and priority in c, I use the following >> function in das_watchdog: >> >> static int set_pid_priority(pid_t pid,int policy,int priority,char >> *message,char *name){ >> struct sched_param par={0}; >> par.sched_priority=priority; >> if((sched_setscheduler(pid,policy,&par)!=0)){ >> print_error(stderr,message,pid,name,strerror(errno)); >> return 0; >> } >> return 1; >> } >> >> >> >> To set normal priority for a process, it can be called like this: >> >> set_pid_priority(pid,SCHED_OTHER,0,"Could not set pid %d (\"%s\") to >> SCHED_OTHER (%s).\n","no name")) >> >> > > From taube at uiuc.edu Tue Aug 11 13:13:33 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Tue, 11 Aug 2009 15:13:33 -0500 Subject: [CM] Fwd: Linux/Midi Test In-Reply-To: References: <4A81B92B.9050807@gmail.com> <4A81C94F.5030506@gmail.com> Message-ID: <2BA1DC61-FAC4-4966-BA0C-F84CC7208C13@uiuc.edu> ok i added kjetil's / andrews mods to juce_amalgamated.cpp and checked it into svn. lieven if you svn update make and run that little process example again hopefully you were hear a more stable sound: (define (simp reps rate dur low hi) (process repeat reps do (send "mp:midi" :key (between low hi) :dur dur) (wait rate))) (sprout (simp 100 0.25 0.125 64 72)) thank you kjetil and andrew for being so helpful! From dfsextras at cox.net Tue Aug 11 17:52:04 2009 From: dfsextras at cox.net (Denis Fitzpatrick) Date: Tue, 11 Aug 2009 19:52:04 -0500 Subject: [CM] first fomus efforts, maybe a bug? Message-ID: <4A821234.3080505@cox.net> When I run the fomus example 1, then fomus example 8 then example 1 again, the results from the first and second runs differ in their labeling of the staff, no labels in the first run, flute and tube labels in the second (pdfs attached). Seems wrong.... Also, anyway to pass a filename to the pdf from Grace? Nevertheless, loving it. Denis Fitzpatrick -------------- next part -------------- A non-text attachment was scrubbed... Name: Ex1First.pdf Type: application/pdf Size: 24674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ex1ThirdAFterex8.pdf Type: application/pdf Size: 23991 bytes Desc: not available URL: From dfsextras at cox.net Tue Aug 11 17:57:53 2009 From: dfsextras at cox.net (Denis Fitzpatrick) Date: Tue, 11 Aug 2009 19:57:53 -0500 Subject: [CM] first fomus efforts, maybe a bug? In-Reply-To: <4A821234.3080505@cox.net> References: <4A821234.3080505@cox.net> Message-ID: <4A821391.1050107@cox.net> Ahh, should have said running Grace 3.3.0 with Fomus (beta1) on OS X 10.5.8 Denis Fitzpatrick wrote: > When I run the fomus example 1, then fomus example 8 then example 1 > again, the results from the first and second runs differ in their > labeling of the staff, no labels in the first run, flute and tube > labels in the second (pdfs attached). Seems wrong.... > Also, anyway to pass a filename to the pdf from Grace? > > Nevertheless, loving it. > Denis Fitzpatrick > ------------------------------------------------------------------------ > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > From dfsextras at cox.net Tue Aug 11 18:07:00 2009 From: dfsextras at cox.net (Denis Fitzpatrick) Date: Tue, 11 Aug 2009 20:07:00 -0500 Subject: [CM] first fomus efforts, maybe a bug? In-Reply-To: <4A821234.3080505@cox.net> References: <4A821234.3080505@cox.net> Message-ID: <4A8215B4.4090404@cox.net> By reading the documentation: send "fms:new-score" > Also, anyway to pass a filename to the pdf from Grace? From dpsenick at cox.net Tue Aug 11 19:43:18 2009 From: dpsenick at cox.net (David Psenicka) Date: Tue, 11 Aug 2009 21:43:18 -0500 Subject: [CM] first fomus efforts, maybe a bug? In-Reply-To: <4A821391.1050107@cox.net> References: <4A821234.3080505@cox.net> <4A821391.1050107@cox.net> Message-ID: <4A822C46.7080701@cox.net> An HTML attachment was scrubbed... URL: From dfsextras at cox.net Tue Aug 11 20:43:59 2009 From: dfsextras at cox.net (Denis Fitzpatrick) Date: Tue, 11 Aug 2009 22:43:59 -0500 Subject: [CM] list* == unbound variable Message-ID: <4A823A7F.8040401@cox.net> print list*(1,2,3, {a b c}) ; from lists.sal produces >>> Error: list*: unbound variable in: FOMUS 0.1-alpha (c) 2009 David Psenicka Grace 3.3.0 (c) 2009 Todd Ingalls, Rick Taube JUCE v1.46 (c) 2009 Julian Storer SndLib 21.0 (c) 2009 William Schottstaedt /\\\ ---\\\--------- ----\\\-------- ----/\\\------- Common Music 3.3.0 ---/--\\\------ --/----\\\----- / \\\/ From taube at uiuc.edu Wed Aug 12 04:50:03 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Wed, 12 Aug 2009 06:50:03 -0500 Subject: [CM] list* == unbound variable In-Reply-To: <4A823A7F.8040401@cox.net> References: <4A823A7F.8040401@cox.net> Message-ID: <6DFBD3BD-D407-4FA4-A50C-516803B019CF@uiuc.edu> oh thats a mistake in cm.html, i replaced 'list*' with the more general 'concat', which sticks lists and non-lists together. your example: print concat(1, 2, 3, {a b c}) any input can be a list: print concat( 1, {2 3}, 4 ,{a b c}) On Aug 11, 2009, at 10:43 PM, Denis Fitzpatrick wrote: > print list*(1,2,3, {a b c}) ; from lists.sal > produces >>>> Error: list*: unbound variable From k.s.matheussen at notam02.no Wed Aug 12 06:29:22 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed, 12 Aug 2009 15:29:22 +0200 (CEST) Subject: [CM] Syntactic changes to snd-rt Message-ID: I've added a few improvements to the syntax of snd-rt. What I like most is the use of the keywords ":where" and ":when" which can be placed anywhere in code. (inspired by various functional languages) ":where" is a postfix operator to add local variables, and ":when" is a postfix operator for doing conditional tests. Personally, I think code can becomes more gentle when using these operators. For the use of ":where", it is nice to know what you want to do with a variable, before it is created. And similarly, for the use of ":when', it is nice to know the action you may want to do, before checking whether you want to do it. Example below is the (usual) midi synthesizer using this new syntax: (It looks much better in emacs with the "rt-DotEmacs" file loaded!) ( (define (midi-synth) (while #t (wait-midi :command note-on (sound (out (* (-> adsr next) (midi-vol) (oscil :freq (midi-to-freq (midi-note))))) (stop :when (-> adsr is-finished))) (spawn (wait-midi :command note-off :note (midi-note) (-> adsr stop))) :where adsr (make-adsr :a 20:-ms :d 30:-ms :s 0.2 :r 70:-ms)))) (define (reverb input) (+ (* 0.5 dry) (* 0.1 wet) :where dry input :where wet (+ (comb :scaler 0.742 :size 9601 allpass-sum) (comb :scaler 0.733 :size 10007 allpass-sum) (comb :scaler 0.715 :size 10799 allpass-sum) (comb :scaler 0.697 :size 11597 allpass-sum) :where allpass-sum (send input :through (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7))))) (sound (out (reverb (in (midi-synth)))))) The same code, but without using :when and :where: ( (define (midi-synth) (while #t (wait-midi :command note-on (define adsr (make-adsr :a 20:-ms :d 30:-ms :s 0.2 :r 70:-ms)) (sound (out (* (-> adsr next) (midi-vol) (oscil :freq (midi-to-freq (midi-note))))) (if (-> adsr is-finished) (stop))) (spawn (wait-midi :command note-off :note (midi-note) (-> adsr stop)))))) (define (reverb input) (define dry input) (define wet (let ((allpass-sum (send input :through (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7)))) (+ (comb :scaler 0.742 :size 9601 allpass-sum) (comb :scaler 0.733 :size 10007 allpass-sum) (comb :scaler 0.715 :size 10799 allpass-sum) (comb :scaler 0.697 :size 11597 allpass-sum)))) (+ (* 0.5 dry) (* 0.1 wet))) (sound (out (reverb (in (midi-synth)))))) From taube at uiuc.edu Wed Aug 12 06:34:54 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Wed, 12 Aug 2009 08:34:54 -0500 Subject: [CM] linux nits Message-ID: i finally got midi sound on my linux virtual machine working and with the sendMessageNow() patch 2 voices at .125 rate sounds quite steady with processes in lock step. thanks to all who helped improve this! i notice two other issues: 1 copy/paste mechanism doesn seem to work except inside the app. im just using juce copy/paste lieven mentioned some x pasteboard -- if thats what i need to use any idea how i would intergrate that into the app? it would be nice to copy from a terminal or emacs and be able to paste into a grace editor for example. 2 when my mouse is idle hovering over a menubar menu, or idle in a text editor, some process somewhere starts periodically turning my mouse pointer in to a "spinning ball" icon (the ball has little dots in it but i dont know what they mean...) and then turning it back into a pointer about a second later. this happens once every 4 to six seconds. any idea what could be doing this or what the icon means? I didnt notice this on andrews box and wonder what it could be due to. it seems to happen more frequently when i have a midi connection made but im not sure. it also happens without any connection. From k.s.matheussen at notam02.no Wed Aug 12 09:04:36 2009 From: k.s.matheussen at notam02.no (Kjetil S. Matheussen) Date: Wed, 12 Aug 2009 18:04:36 +0200 (CEST) Subject: [CM] Syntactic changes to snd-rt In-Reply-To: References: Message-ID: On Wed, 12 Aug 2009, Kjetil S. Matheussen wrote: > > I've added a few improvements to the syntax of snd-rt. > What I like most is the use of the keywords ":where" and > ":when" which can be placed anywhere in code. (inspired > by various functional languages) > > ":where" is a postfix operator to add local variables, > and ":when" is a postfix operator for doing conditional tests. > Not quite used to the new syntax yet. Here is another version of the softsynth which exploits it better: ( (sound (out (+ (* 0.5 softsynth) (* 0.1 reverb) :where reverb (+ (comb :scaler 0.742 :size 9601 allpass-sum) (comb :scaler 0.733 :size 10007 allpass-sum) (comb :scaler 0.715 :size 10799 allpass-sum) (comb :scaler 0.697 :size 11597 allpass-sum) :where allpass-sum (send softsynth :through (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7) (all-pass :feedback -0.7 :feedforward 0.7))) :where softsynth (in (while #t (wait-midi :command note-on (sound (out (* (-> adsr next) (midi-vol) (oscil :freq (midi-to-freq (midi-note))))) (stop :when (-> adsr is-finished))) (spawn (wait-midi :command note-off :note (midi-note) (-> adsr stop))) :where adsr (make-adsr :a 20:-ms :d 30:-ms :s 0.2 :r 70:-ms)))))))) From taube at uiuc.edu Thu Aug 13 19:07:29 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Thu, 13 Aug 2009 21:07:29 -0500 Subject: [CM] Grace with Fomus beta2 Message-ID: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> a beta2 binary of grace with fomus and sndlib is temporarily available at (all one line): http://camil.music.uiuc.edu/Software/grace/downloads/grace-with-fomus-osx-beta2.zip fomus: important bug fixes, title and author settings added, examples in fomusexamples.sal now use explicit output filenames. cm: ive switched to bill's new read-time macroexpander. the CM macros 'process' 'loop' and all functions that have opt/key args use this new feature , which should make calling these things in "real time" much cleaner. however this is a very pervasive and lowlevel change so if you have trouble with anything please let me know. ive also been able to get scheme errors to pop the Console window to the top as well as beep, and i fixed a bug where i wasnt closing the string output ports i was opening! if you build from svn you MUST download and install the latest sndlib tarball because im depending on bill's 'define-expansion' feature being there. ftp://ccrma-ftp.stanford.edu/pub/Lisp/sndlib.tar.gz From eichhoff at statistik.tu-dortmund.de Fri Aug 14 00:20:28 2009 From: eichhoff at statistik.tu-dortmund.de (Markus Eichhoff) Date: Fri, 14 Aug 2009 09:20:28 +0200 Subject: [CM] Grace with Fomus beta2 In-Reply-To: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> Message-ID: <4A85103C.8000001@statistik.tu-dortmund.de> is the beta2 version also available for linux or windows? Heinrich Taube schrieb: > a beta2 binary of grace with fomus and sndlib is temporarily available > at (all one line): > > http://camil.music.uiuc.edu/Software/grace/downloads/grace-with-fomus-osx-beta2.zip > > fomus: important bug fixes, title and author settings added, examples > in fomusexamples.sal now use explicit output filenames. > > cm: ive switched to bill's new read-time macroexpander. the CM macros > 'process' 'loop' and all functions that have opt/key args use this new > feature , which should make calling these things in "real time" much > cleaner. however this is a very pervasive and lowlevel change so if > you have trouble with anything please let me know. ive also been able > to get scheme errors to pop the Console window to the top as well as > beep, and i fixed a bug where i wasnt closing the string output ports > i was opening! > > if you build from svn you MUST download and install the latest sndlib > tarball because im depending on bill's 'define-expansion' feature > being there. > > ftp://ccrma-ftp.stanford.edu/pub/Lisp/sndlib.tar.gz > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > -- Dipl.-Math. Markus Eichhoff Chair of Computational Statistics Faculty of Statistics Technical University of Dortmund 44221 Dortmund Room: M826 Phone: +49 (0)231 755 - 5903 Telefax: +49 (0)231 755 - 4387 E-mail: eichhoff at statistik.tu-dortmund.de Web: http://www.statistik.tu-dortmund.de/eichhoff_eng.html From rm at seid-online.de Fri Aug 14 02:03:38 2009 From: rm at seid-online.de (Ralf Mattes) Date: Fri, 14 Aug 2009 11:03:38 +0200 Subject: [CM] Grace with Fomus beta2 In-Reply-To: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> Message-ID: <1250240618.6850.6.camel@mhflaptop01> On Thu, 2009-08-13 at 21:07 -0500, Heinrich Taube wrote: > a beta2 binary of grace with fomus and sndlib is temporarily available > at (all one line): > > http://camil.music.uiuc.edu/Software/grace/downloads/grace-with-fomus-osx-beta2.zip > > fomus: important bug fixes, title and author settings added, examples > in fomusexamples.sal now use explicit output filenames. > > cm: ive switched to bill's new read-time macroexpander. the CM macros > 'process' 'loop' and all functions that have opt/key args use this new > feature , which should make calling these things in "real time" much > cleaner. however this is a very pervasive and lowlevel change so if > you have trouble with anything please let me know. ive also been able > to get scheme errors to pop the Console window to the top as well as > beep, and i fixed a bug where i wasnt closing the string output ports > i was opening! > > if you build from svn you MUST download and install the latest sndlib > tarball because im depending on bill's 'define-expansion' feature > being there. > > ftp://ccrma-ftp.stanford.edu/pub/Lisp/sndlib.tar.gz > Hmm - I get this error during compile gcc headers.o audio.o io.o sound.o xen.o vct.o clm.o sndlib2xen.o clm2xen.o midi.o run.o s7.o -o libsndlib.so -shared -lasound -lsamplerate -L/usr/lib -lgsl -lgslcblas -lm -ljack -lpthread -lrt ar -rc libsndlib.a headers.o audio.o io.o sound.o xen.o vct.o clm.o sndlib2xen.o clm2xen.o midi.o run.o s7.o -ljack -lpthread -lrt ar: -ljack: No such file or directory This is for a build configured like this: ./configure --with-s7 --with-jack --with-alsa And, of course, libjack _is_ installed in the default system location ... AFAIK the problem seems to only show up when configuring with both alsa and jack - configuring for a single backend comiles/links without problems. Maybe a conditional compile and static versions ( libsndlib-jack.a, libsndlib-alsa.a ... etc.) might be an option. HTH Ralf Mattes > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Fri Aug 14 02:59:17 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Fri, 14 Aug 2009 04:59:17 -0500 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <4A85103C.8000001@statistik.tu-dortmund.de> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> Message-ID: <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> > > is the beta2 version also available for linux or windows? > i think david is working on a windows binary. fomus works on linux because that's davids main environment for working so you could cerntainly build things there. to compile the whole sndlib + fomus + cm software i think youd do it like this compile and install the latest boost distribution (1.39.0 ?) compile and install fomus to /usr/local compile sndlib compile grace From rm at seid-online.de Fri Aug 14 03:21:59 2009 From: rm at seid-online.de (Ralf Mattes) Date: Fri, 14 Aug 2009 12:21:59 +0200 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> Message-ID: <1250245319.6850.13.camel@mhflaptop01> On Fri, 2009-08-14 at 04:59 -0500, Heinrich Taube wrote: > > > > is the beta2 version also available for linux or windows? > > > > i think david is working on a windows binary. fomus works on linux > because that's davids main environment for working so you could > cerntainly build things there. to compile the whole sndlib + fomus + > cm software i think youd do it like this > > compile and install the latest boost distribution (1.39.0 ?) > compile and install fomus to /usr/local > compile sndlib > compile grace Struggling with this myself just now: Fomus seems to rely on rather new versions of autoconf/automake - at least here (Ubuntu 8.10, automake 1.9.6) a _lot_ of m4 macros are missing. The easiest way to fix this: + download a recent version of the autoconf archives: wget http://downloads.sourceforge.net/project/ac-archive/ac-archive/2007.0205/ac-archive-2007.0205.tar.bz2 + unpack the archive tar xvjf ac-archive-2007.0205.tar.bz2 + edit 'bootstrap - aclocal >/dev/null 2>&1 + aclocal -I ac-archive-2007.0205 >/dev/null 2>&1 + rerun bootstrap + run configure / make / sudo make install HTH Ralf Mattes > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Fri Aug 14 03:42:00 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Fri, 14 Aug 2009 05:42:00 -0500 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <1250245319.6850.13.camel@mhflaptop01> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> <1250245319.6850.13.camel@mhflaptop01> Message-ID: <5224C6CB-1611-4319-A53D-969D426D48DC@uiuc.edu> ive posted Davids tarball that I used to compile beta2 that should ./ configure on your system http://camil.music.uiuc.edu/Software/grace/downloads/fomus-0.1.2-alpha.tar.gz also when you build sndlib on linux it may save a .so in addtion to a .a -- delete the .so if you are building grace, for some reason linking gets confused and tries to use the .so instead of the .a even though i expictly provide the .a extension On Aug 14, 2009, at 5:21 AM, Ralf Mattes wrote: > On Fri, 2009-08-14 at 04:59 -0500, Heinrich Taube wrote: >>> >>> is the beta2 version also available for linux or windows? >>> From bil at ccrma.Stanford.EDU Fri Aug 14 04:29:18 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 14 Aug 2009 04:29:18 -0700 Subject: [CM] Grace with Fomus beta2 In-Reply-To: <1250240618.6850.6.camel@mhflaptop01> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <1250240618.6850.6.camel@mhflaptop01> Message-ID: <20090814112743.M54136@ccrma.Stanford.EDU> > ar: -ljack: No such file or directory I think this is a bug in the sndlib makefile. The documentation says ar ignores -l args, but now it seems to complain about them. You can get the thing to build libsndlib.a by deleting the -l args to the ar command. I'll fix the makefile -- thanks for the bug report! From andersvi at notam02.no Fri Aug 14 04:48:33 2009 From: andersvi at notam02.no (andersvi at notam02.no) Date: Fri, 14 Aug 2009 13:48:33 +0200 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> (Heinrich Taube's message of "Fri, 14 Aug 2009 04:59:17 -0500") References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> Message-ID: <87fxbulipa.fsf@notam02.no> H> compile and install the latest boost distribution (1.39.0 ?) Ive only managed using boost v. 1.35 w. fomus. -anders From eichhoff at statistik.tu-dortmund.de Fri Aug 14 04:55:30 2009 From: eichhoff at statistik.tu-dortmund.de (Markus Eichhoff) Date: Fri, 14 Aug 2009 13:55:30 +0200 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <87fxbulipa.fsf@notam02.no> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> <87fxbulipa.fsf@notam02.no> Message-ID: <4A8550B2.7080100@statistik.tu-dortmund.de> Oh my god... it sounds so complicated what you all are doing. I hope that the bugs don't bite you. :-) Now I still work with the older version, use the music instruments in sndlib which works very well. If I use the random-thing then I will try to write the function in C, but at the moment I am still busy, so I have no time to do that. andersvi at notam02.no schrieb: > H> compile and install the latest boost distribution (1.39.0 ?) > > Ive only managed using boost v. 1.35 w. fomus. > > -anders > From andersvi at notam02.no Fri Aug 14 05:12:46 2009 From: andersvi at notam02.no (andersvi at notam02.no) Date: Fri, 14 Aug 2009 14:12:46 +0200 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <4A8550B2.7080100@statistik.tu-dortmund.de> (Markus Eichhoff's message of "Fri, 14 Aug 2009 13:55:30 +0200") References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> <87fxbulipa.fsf@notam02.no> <4A8550B2.7080100@statistik.tu-dortmund.de> Message-ID: <87bpmilhkx.fsf@notam02.no> >>>>> "M" == Markus Eichhoff writes: M> Oh my god... it sounds so complicated what you all are doing. apt-get install libboost1.35-dev or something similar... From taube at uiuc.edu Fri Aug 14 05:23:25 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Fri, 14 Aug 2009 07:23:25 -0500 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <4A8550B2.7080100@statistik.tu-dortmund.de> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> <87fxbulipa.fsf@notam02.no> <4A8550B2.7080100@statistik.tu-dortmund.de> Message-ID: well..thats why we are trying to make binary distributions. anyway source building isnt all that bad, and well worth it -- you get a free environment with sndlib (40 years of ccrma audio synthesis!) and fomus manuscripting, which is really incredible. On Aug 14, 2009, at 6:55 AM, Markus Eichhoff wrote: > Oh my god... it sounds so complicated what you all are doing. I hope > that the bugs don't bite you. :-) From dpsenick at cox.net Fri Aug 14 09:25:26 2009 From: dpsenick at cox.net (David Psenicka) Date: Fri, 14 Aug 2009 11:25:26 -0500 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <1250245319.6850.13.camel@mhflaptop01> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> <1250245319.6850.13.camel@mhflaptop01> Message-ID: <4A858FF6.4050409@cox.net> An HTML attachment was scrubbed... URL: From taube at uiuc.edu Fri Aug 14 10:30:15 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Fri, 14 Aug 2009 12:30:15 -0500 Subject: [CM] beta2 (fomus on windows and linux) In-Reply-To: <4A858FF6.4050409@cox.net> References: <306BB69A-2CA8-49CB-89C3-9E4AFE4BA0E3@uiuc.edu> <4A85103C.8000001@statistik.tu-dortmund.de> <86A12B2E-6AB2-46E1-82F2-B0E1B3BDC14C@uiuc.edu> <1250245319.6850.13.camel@mhflaptop01> <4A858FF6.4050409@cox.net> Message-ID: can a script (on osx, say) download and compile fomus? On Aug 14, 2009, at 11:25 AM, David Psenicka wrote: > The fomus tarballs should be much easier to build than the SVN > version, you won't need the autoconf-archive, or several more extra > packages for building the documentation. The only dependencies for > the tarballs are the boost headers and libs. Today I should finally > get my sourceforge site together and have an actual release w/ some > documentation and at least a few examples. I'll release new > tarballs pretty quickly after I make changes, so the tarballs won't > be very far behind the SVN version. > > Any boost >= v. 1.35 should work (I've tested 1.35 and 1.39, I'm > assuming everything in between is ok)--the issue with boost libs is > that their installer doesn't seem to put anything in the right > place, you'll have to move the boost headers directory to the right > place and possible move the libraries out of their "stage" directory > and into your libs directory. > > Also, I almost have this thing working in Windows on cygwin (I'm not > sure how Windows users feel about cygwin, but it was actually much > easier to get it building properly there than w/ cisual studio.) > The issue I have to fix there has to do w/ path mixups between > cygwin's directory system and Window's, that could take me a day or > two to work out (especially on my poky old windows machine) From s_boussuge at yahoo.fr Thu Aug 20 02:00:40 2009 From: s_boussuge at yahoo.fr (stephane boussuge) Date: Thu, 20 Aug 2009 11:00:40 +0200 Subject: [CM] ffi unbound variable with use of discrete Message-ID: hi, it seem to have a bug in last version of grace (3.3.0) when i try the mapping example : loop repeat 20 for x = ran(1.0) for d = discrete(x, 0.0, 1.0, 48, 90) print "x=", x, " d=", d end i've a: ffi_discrete: unbound variable>>> Error: ffi_discrete: unbound variable cheers stf From taube at uiuc.edu Fri Aug 21 11:06:53 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Fri, 21 Aug 2009 13:06:53 -0500 Subject: [CM] ffi unbound variable with use of discrete In-Reply-To: References: Message-ID: <1A2D71D2-6BE2-4ADB-BAAA-AC8D0B26B805@uiuc.edu> thanks for the bug report, this was a typo in the ffi and it is fixed in svn trunk: loop repeat 20 for x = ran(1.0) for d = discrete(x, 0.0, 1.0, 48, 90) print "x=", x, " d=", d end x=0.089581334052976 d=51 x=0.96876784203778 d=88 x=0.49723472411214 d=68 x=0.082061355952653 d=51 x=0.067180768369506 d=50 x=0.90651566556341 d=86 x=0.81225912478107 d=82 x=0.62658593445704 d=74 x=0.31612700487397 d=61 x=0.24943431682173 d=58 x=0.33439247154966 d=62 x=0.87126396989246 d=84 x=0.41610700996036 d=65 x=0.025761402218081 d=49 x=0.53223813058162 d=70 x=0.79803604884027 d=81 x=0.75465513666967 d=79 x=0.15027466536273 d=54 x=0.41939716306967 d=65 x=0.18762388131293 d=55 btw im making the binary release this weekend so if anyone has a bug to report now is the time! From paul_kirk at mac.com Mon Aug 24 12:34:17 2009 From: paul_kirk at mac.com (Paul Kirk) Date: Mon, 24 Aug 2009 12:34:17 -0700 Subject: [CM] CLM Platforms Message-ID: Does CLM run on the Mac OSX 10.5.7 ( Leopard)? If it does what flavor of LISP is recommended for the OSX platform? Thanks, Paul From bil at ccrma.Stanford.EDU Mon Aug 24 12:41:01 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Mon, 24 Aug 2009 12:41:01 -0700 Subject: [CM] CLM Platforms In-Reply-To: References: Message-ID: <20090824193946.M28193@ccrma.Stanford.EDU> > Does CLM run on the Mac OSX 10.5.7 ( Leopard)? If it does what flavor > of LISP is recommended for the OSX platform? yes, it runs (I'm running 10.5.8 right now). I like both sbcl and clisp. From taube at uiuc.edu Wed Aug 26 09:18:29 2009 From: taube at uiuc.edu (Heinrich Taube) Date: Wed, 26 Aug 2009 11:18:29 -0500 Subject: [CM] Announce: Chorale Composer 0.9 Message-ID: <61877C5F-4F3C-4B08-83E8-09DA3FDFD79F@uiuc.edu> Chorale Composer 0.9 is available for download at: http://camil.music.uiuc.edu/Software/cc/index.html Chorale Composer is a cross-platform application implemented in JUCE that demonstrates automatic, real-time tonal music analysis and device independent music notation services. It contains an almost complete edition of the Bach Chorales as its source material. Use Chorale Composer to play, edit and analyze the Bach Chorales in real time, or to practice example theory exercises that demonstrate the program's support of automatic music theory instruction at the university level. New Features: * Improvements to analysis display (tonicizations are distinguished from modulations) * Improvements to tonality (key area) display. * Unicode support, including proper German lettering in Chorale titles. * Incipits from the original Riemenschneider edition * Many new GUI features and shortcuts, including Scroll wheel for scrolling and Shift-Scroll wheel for zooming Andrew Burnson Rick Taube From ja.lira0 at gmail.com Fri Aug 28 11:27:05 2009 From: ja.lira0 at gmail.com (James) Date: Fri, 28 Aug 2009 14:27:05 -0400 Subject: [CM] Common Music in Emacs Message-ID: I have set up CM as a Emacs inferior process in LISP mode and using it to run code examples from Notes from the Meta-Level. For some reason I get an unbound variable error when I try to call "events": (events (play-harms2 4) "harms.mid" :channel-tuning 108) ;events: unbound variable error (events (clearbends ) "clearbends.mid") ;events: unbound variable error Does anybody know why this is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Sat Aug 29 11:41:54 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sat, 29 Aug 2009 11:41:54 -0700 Subject: [CM] snd regions Message-ID: <20090829182348.M36129@ccrma.Stanford.EDU> I have been using Snd for 12 years now, and I have never found any real use for regions. I think they should be removed. Would this be a problem for anyone? (They preceded the extension language, and seemed like a good idea because I thought everything had to be accessible from the GUI, and disk space was tight!) From ja.lira0 at gmail.com Sat Aug 29 18:20:40 2009 From: ja.lira0 at gmail.com (James) Date: Sat, 29 Aug 2009 21:20:40 -0400 Subject: [CM] Common Music in Emacs In-Reply-To: References: Message-ID: Okay so I've figured out that it's a deprecated function from CM-2.. What is it's equivalent in CM-3? I can't find this in the dictionary. How much of the Meta-Level code would require translation? I'm wondering if it would be more worth it to try to install CM-2 but I'm finding this difficult. Any help as ever is appreciated. James On Fri, Aug 28, 2009 at 2:27 PM, James wrote: > I have set up CM as a Emacs inferior process in LISP mode and using it to > run code examples from Notes from the Meta-Level. For some reason I get an > unbound variable error when I try to call "events": > > (events (play-harms2 4) "harms.mid" :channel-tuning 108) > ;events: unbound variable > error > > (events (clearbends ) "clearbends.mid") > ;events: unbound variable > error > > Does anybody know why this is? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.kroger at gmail.com Sat Aug 29 21:31:02 2009 From: pedro.kroger at gmail.com (Pedro =?utf-8?Q?Kr=C3=B6ger?=) Date: Sat, 29 Aug 2009 21:31:02 -0700 Subject: [CM] Common Music in Emacs References: <87my5iovss.fsf@gmail.com> Message-ID: <87pradorcp.fsf@gmail.com> James writes: > I'm using Ubuntu 8.04. I tried: > cm-2.6.0: When try to run the cm.sh script or load the cm.lisp in > clisp I get a segmentation fault error. > cm-2.4.2 (the version bundled with the book): The script says my clisp is incompatible.. you may want to try cm-2.8.0. I could run cm.sh with clisp 2.47 here. pedro From bil at ccrma.Stanford.EDU Sun Aug 30 06:57:03 2009 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 30 Aug 2009 06:57:03 -0700 Subject: [CM] generic fft Message-ID: <20090830135551.M86663@ccrma.Stanford.EDU> I mentioned earlier the generic fft. Here is the complex form: (define* (cfft! data n (dir 1)) (if (not n) (set! n (length data))) (do ((i 0 (+ i 1)) (j 0)) ((= i n)) (if (> j i) (let ((temp (data j))) (set! (data j) (data i)) (set! (data i) temp))) (let ((m (/ n 2))) (do () ((or (< m 2) (< j m))) (set! j (- j m)) (set! m (/ m 2))) (set! j (+ j m)))) (let ((ipow (floor (log n 2))) (prev 1)) (do ((lg 0 (+ lg 1)) (mmax 2 (* mmax 2)) (pow (/ n 2) (/ pow 2)) (theta (make-rectangular 0.0 (* pi dir)) (* theta 0.5))) ((= lg ipow)) (let ((wpc (exp theta)) (wc 1.0)) (do ((ii 0 (+ ii 1))) ((= ii prev)) (do ((jj 0 (+ jj 1)) (i ii (+ i mmax)) (j (+ ii prev) (+ j mmax))) ((>= jj pow)) (let ((tc (* wc (data j)))) (set! (data j) (- (data i) tc)) (set! (data i) (+ (data i) tc)))) (set! wc (* wc wpc))) (set! prev mmax)))) data) > (cfft! (list 0.0 1+i 0.0 0.0)) (1+1i -1+1i -1-1i 1-1i) > (cfft! (vector 0.0 1+i 0.0 0.0)) #(1+1i -1+1i -1-1i 1-1i) ;; check against built-in FFT > (let ((rl (vct 0.0 1.0 0.0 0.0)) (im (vct 0.0 1.0 0.0 0.0))) (mus-fft rl im) (map make-rectangular (vct->list rl) (vct->list im))) (1+1i -1+1i -1-1i 1-1i)