From j_hearon at hotmail.com  Mon Oct  7 10:31:17 2013
From: j_hearon at hotmail.com (James Hearon)
Date: Mon, 7 Oct 2013 17:31:17 +0000
Subject: [CM] emacs, slime fancy commands, clm
In-Reply-To: <mailman.3.1378494002.12998.cmdist@ccrma.stanford.edu>
References: <mailman.3.1378494002.12998.cmdist@ccrma.stanford.edu>
Message-ID: <BLU168-W122B99DECBAC4A96BF4D7C4E5130@phx.gbl>

Hi,
It took me a while to finally grok this--to be able to write code in a .lisp file and compile and load it, but it seems something called slime fancy commands provides an answer.

M-x slime-compile-and-load-file

(definstrument examp1 (start-time duration frequency amplitude)
  (let* ((beg (floor (* start-time *srate*)))
     (end (+ beg (floor (* duration *srate*))))
     (j 0))
    (run
      (loop for i from beg below end do
        (outa i (* amplitude (sin (* j 2.0 pi (/ frequency *srate*)))))
    (incf j)))))

(with-sound () (examp1 0 3.25 440.0 0.75))

So I can do this all in one step in emacs now (after M-x slime, then (load "all.lisp")), and that helps with tweaking the instrument code in the buffer as opposed to loading and compiling an .ins file.  I guessing that's probably going backwards in terms of how/why those files (.ins, .fasl, .clm) developed, and once the instrument is tweaked out, then I can see it's probably best to go ahead and create an .ins file out of the .lisp file, but the .lisp file seems to make it easier for designing instruments in the emacs editor.  

Am I on the right track here, or is there some compelling reason to employ .ins files in CLM for designing an instrument in the emacs editor?

Regards,
Jim


>    1. emacs, slime, sbcl, clm (James Hearon)
>    2. Re: emacs, slime, sbcl, clm (Bill Schottstaedt)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 6 Sep 2013 18:08:25 +0000
> From: James Hearon <j_hearon at hotmail.com>
> Subject: [CM] emacs, slime, sbcl, clm
> To: "cmdist at ccrma.Stanford.EDU" <cmdist at ccrma.Stanford.EDU>
> Message-ID: <BLU168-W6088784E43A4B984C0C0F1E53C0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> I'm getting myself confused about how to evaluate a clm .lisp file in emacs.
> 
> I tried evaluating the inst below but get a lisp error: (void-function with-sound).
> 
> (definstrument examp1 (start-time duration frequency amplitude)
>   (let* ((beg (floor (* start-time *srate*)))
>      (end (+ beg (floor (* duration *srate*))))
>      (j 0))
>     (run
>       (loop for i from beg below end do
>         (outa i (* amplitude (sin (* j 2.0 pi (/ frequency *srate*)))))
>     (incf j)))))
> 
> (with-sound () (examp1 0 3.25 440.0 0.75))
> 
> I did a load all.lisp before evaluating and all the .fasl files are generated etc.  Also the compile-file, then load, and finally with-sound approach is working o.k. for .ins files, but I was trying to code an inst using a .lisp file and evaluating from emacs so I could play then edit(tweak) from the buffer.  Does that approach not work?
> 
> Regards,
> Jim
>  		 	   		  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://ccrma-mail.stanford.edu/mailman/private/cmdist/attachments/20130906/2a94fa56/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 6 Sep 2013 11:48:33 -0700
> From: "Bill Schottstaedt" <bil at ccrma.Stanford.EDU>
> Subject: Re: [CM] emacs, slime, sbcl, clm
> To: James Hearon <j_hearon at hotmail.com>,	"cmdist at ccrma.Stanford.EDU"
> 	<cmdist at ccrma.Stanford.EDU>
> Message-ID: <20130906184636.M74072 at ccrma.Stanford.EDU>
> Content-Type: text/plain;	charset=iso-8859-1
> 
> You do need to compile the instrument code in the CL clm -- the compiler
> forces the run macro to expand fully, or something like that.  
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
> 
> 
> End of Cmdist Digest, Vol 65, Issue 1
> *************************************
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20131007/14e968b9/attachment.html>

From bil at ccrma.Stanford.EDU  Mon Oct  7 12:11:15 2013
From: bil at ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Mon, 7 Oct 2013 12:11:15 -0700
Subject: [CM] emacs, slime fancy commands, clm
In-Reply-To: <BLU168-W122B99DECBAC4A96BF4D7C4E5130@phx.gbl>
References: <mailman.3.1378494002.12998.cmdist@ccrma.stanford.edu>
	<BLU168-W122B99DECBAC4A96BF4D7C4E5130@phx.gbl>
Message-ID: <20131007190944.M10549@ccrma.Stanford.EDU>

The *.ins files are just a convenience. The ins extension goes back to
the ancients -- the real ancients! -- before my time.



From Michael.Rogulla at SIZ.DE  Sun Oct 13 04:10:44 2013
From: Michael.Rogulla at SIZ.DE (Michael.Rogulla at SIZ.DE)
Date: Sun, 13 Oct 2013 13:10:44 +0200
Subject: [CM] Examples for Grace?
Message-ID: <OF4B4BF5C0.DFE95234-ONC1257C03.003D107F-C1257C03.003D6C25@SIZ>

Hello all,

is there a site (or are there many sites?) dedicated to pieces written for 
Grace?  Or even longer examples? I hope that there must be some kind of 
community of people, working with Grace.

Mikel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20131013/1f67489a/attachment.html>

From bil at ccrma.Stanford.EDU  Mon Oct 14 16:28:00 2013
From: bil at ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Mon, 14 Oct 2013 16:28:00 -0700
Subject: [CM] Snd 14.1
Message-ID: <20131014232648.M76009@ccrma.Stanford.EDU>

Snd 14.1:

removed frame.scm and mixer.scm (frames and mixers have been replaced
  by float-vectors in s7-clm).

checked: gtk 3.9.16, 3.10.0|1, sbcl 1.1.12.

Thanks!: Mike Scholz.



From schiv at archaudio.org  Sun Oct 27 14:04:44 2013
From: schiv at archaudio.org (Ray Rashif)
Date: Mon, 28 Oct 2013 05:04:44 +0800
Subject: [CM] [Snd] 14.x build failure with ladspa, incomplete type error
Message-ID: <CAFEhRJcFWfnhZr94JUD-d-Q=-7EjV=QNUhd-hVEEa2+2X3U0dg@mail.gmail.com>

On 15 October 2013 07:28, Bill Schottstaedt <bil at ccrma.stanford.edu> wrote:
> Snd 14.1:
>
> removed frame.scm and mixer.scm (frames and mixers have been replaced
>   by float-vectors in s7-clm).
>
> checked: gtk 3.9.16, 3.10.0|1, sbcl 1.1.12.

Hi Bill

I couldn't locate a bug tracker so I'm filing this here. Ever since
14.0 I've not had success building snd --with-ladspa:

snd-ladspa.c: In function 'g_ladspa_connect_port':
snd-ladspa.c:1194:32: error: dereferencing pointer to incomplete type
         double_to_float(samples->data, samples->length)
                                ^
snd-ladspa.c:1194:47: error: dereferencing pointer to incomplete type
         double_to_float(samples->data, samples->length)

Here 'samples' is of type vct*. Upon further investigation it appears
the struct definition for vct moved from vct.h to vct.c in 14.0.

There must be a reason for this, but it is beyond my knowledge. For
the meantime, an interim solution is to bring the definition back into
the header.

Patch for workaround inline (copies 13.9 verbatim):

--- snd-14.1.orig/vct.h 2013-10-28 02:22:35.073798054 +0800
+++ snd-14.1/vct.h      2013-10-28 02:45:27.166364791 +0800
@@ -1,11 +1,11 @@
 #ifndef VCT_H
 #define VCT_H

-#if HAVE_SCHEME
-  typedef struct s7_cell vct;
-#else
-typedef struct vct vct;
-#endif
+typedef struct {
+  mus_long_t length;
+  mus_float_t *data;
+  bool dont_free;
+} vct;

 #ifdef __cplusplus
 extern "C" {


--
GPG/PGP ID: C0711BF1



From bil at ccrma.Stanford.EDU  Sun Oct 27 16:59:34 2013
From: bil at ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Sun, 27 Oct 2013 16:59:34 -0700
Subject: [CM] [Snd] 14.x build failure with ladspa, incomplete type error
In-Reply-To: <CAFEhRJcFWfnhZr94JUD-d-Q=-7EjV=QNUhd-hVEEa2+2X3U0dg@mail.gmail.com>
References: <CAFEhRJcFWfnhZr94JUD-d-Q=-7EjV=QNUhd-hVEEa2+2X3U0dg@mail.gmail.com>
Message-ID: <20131027235803.M83517@ccrma.Stanford.EDU>

Thanks very much for the bug report!  I must have messed
up my ladpsa test.  I think the right way to fix this is to
use

    if (descriptor->connect_port) 
      descriptor->connect_port(XEN_TO_C_Ladspa_Handle(ptr),
  			     XEN_TO_C_ULONG(port),
! 			     double_to_float(mus_vct_data(samples), mus_vct_length(samples))
  			     );




From schiv at archaudio.org  Mon Oct 28 03:24:02 2013
From: schiv at archaudio.org (Ray Rashif)
Date: Mon, 28 Oct 2013 18:24:02 +0800
Subject: [CM] [Snd] 14.x build failure with ladspa, incomplete type error
In-Reply-To: <20131027235803.M83517@ccrma.Stanford.EDU>
References: <CAFEhRJcFWfnhZr94JUD-d-Q=-7EjV=QNUhd-hVEEa2+2X3U0dg@mail.gmail.com>
	<20131027235803.M83517@ccrma.Stanford.EDU>
Message-ID: <CAFEhRJfqsOYCeEji2pMhyNqCTVsyi7oo5xth5q-pXkKyo8JCow@mail.gmail.com>

On 28 October 2013 07:59, Bill Schottstaedt <bil at ccrma.stanford.edu> wrote:
> Thanks very much for the bug report!  I must have messed
> up my ladpsa test.  I think the right way to fix this is to
> use
>
>     if (descriptor->connect_port)
>       descriptor->connect_port(XEN_TO_C_Ladspa_Handle(ptr),
>                              XEN_TO_C_ULONG(port),
> !                            double_to_float(mus_vct_data(samples), mus_vct_length(samples))
>                              );

Thanks for the proper fix! Confirmed to be working.


--
GPG/PGP ID: C0711BF1



From anders.vinjar at bek.no  Mon Oct 28 11:46:36 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Mon, 28 Oct 2013 19:46:36 +0100
Subject: [CM] linux-port of OpenMusic
Message-ID: <874n81p71v.fsf@notam02.no>

Hi all.

Ive been working on a linux-port of IRCAMs OpenMusic lately, and think
its approaching a useful state now.

I would very much appreciate it if some of the brave ones out there did
some testing and sent me feedback:

  http://forge.ircam.fr/p/OM6/downloads/label/421/

The tarball you'll find there includes the OM-6.7 image, source code, a
README and the various resources it uses (.so's, libs, fonts, icons,
help-files, tutorials, other).

This beta is not prepared to be installed anywhere, only to be run from
inside the directory where you unpack it (type ./OM_6.7_beta_4 ... ).
Plan is to make an installable version once the dust settles some.

Theres one thing which needs installing to work however, the music-fonts
used in the various editors and factories etc.  Theres an .rpm here:

  http://forge.ircam.fr/p/OM6/downloads/get/omfonts-1.0-1.noarch.rpm.zip

- which hopefully takes care of the fonts (theyre also available for
manual install in the tarball).  The .rpm installs them (4 .ttf-files)
inside its own folder /usr/share/fonts/omfonts/*

The present version uses JACK for audio + midi I/O, and will try to
start a JACK server if its not already running.

To get any sound from the usual midi-ports, the linux-port uses
libfluidsynth, and attempts to load one of the standard soundfonts into
it.  However you should be able to route midi-output to any client you
prefer (with jack-midi support).

Thanks for any feedback.

Cheers,

-anders




From dlphillips at woh.rr.com  Mon Oct 28 12:13:14 2013
From: dlphillips at woh.rr.com (Dave Phillips)
Date: Mon, 28 Oct 2013 15:13:14 -0400
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <874n81p71v.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
Message-ID: <526EB74A.5080907@woh.rr.com>

On 10/28/2013 02:46 PM, anders.vinjar at bek.no wrote:
> Hi all.
>
> Ive been working on a linux-port of IRCAMs OpenMusic lately, and think
> its approaching a useful state now.
>

Hi Anders,

Great news ! I will *definitely* check it out this evening after 
teaching. I tried and reported on older versions for Linux, but nothing 
was really usable then.

Best regards,

dp





From k.s.matheussen at gmail.com  Mon Oct 28 13:42:51 2013
From: k.s.matheussen at gmail.com (Kjetil Matheussen)
Date: Mon, 28 Oct 2013 21:42:51 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <874n81p71v.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
Message-ID: <CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>

Congratulations, It works!

I had to do this first on my fedora box:

yum install fluidsynth-libs.i686
yum install jack-audio-connection-kit.i686


Loading a sound using the Class->Audio->SOUND object causes a segfault
for me though:

Error: Segmentation violation(11) [code 0] at 22527186
     {Offset 1852 inside #<Function (method om-draw-waveform
(soundpanel t)) 22526A4A>}
eax        0 ; ebx        0 ; ecx      200 ; edx 200DDE30
esp 1CEFD5B0 ; ebp 1CEFD690 ; esi       56 ; edi        0
  1 (continue) Remove display-callback from #<soundpanel  24A6AB43>
  2 Remove display-callback from #<soundpanel  24A6AB43>
  3 (abort) Return to event loop.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.

OpenMusic 1 : 1 >
; Loading text file /home/kjetil/openmusic_testworkspace/elements/Patch 2.omp
; Loading text file /home/kjetil/openmusic_testworkspace/elements/Patch 2.omp
:b
Call to capi-gtk-library::with-gdk-unlocked-debugger-wrapper
Call to invoke-debugger
Call to error
Call to (method om-draw-waveform (soundpanel t))
Call to (method om-draw-contents (soundpanel))
Call to clos::method-combination-template
Call to (subfunction 2 (method capi:draw-pinboard-object (t
om-api::om-view-pinboard-object)))
Call to capi:execute-with-interface
Call to capi:apply-in-pane-process
Call to clos::method-combination-template
Call to (method capi::draw-pinboard-objects (t t t t t t))
Call to (method capi::pinboard-pane-display-region
(capi::pinboard-redraw-object t t t t t))
Call to (method capi-internals:output-pane-display (capi:output-pane t t t t))
Call to capi-gtk-library::expose-event-display-inside-lock-2



On Mon, Oct 28, 2013 at 7:46 PM,  <anders.vinjar at bek.no> wrote:
> Hi all.
>
> Ive been working on a linux-port of IRCAMs OpenMusic lately, and think
> its approaching a useful state now.
>
> I would very much appreciate it if some of the brave ones out there did
> some testing and sent me feedback:
>
>   http://forge.ircam.fr/p/OM6/downloads/label/421/
>
> The tarball you'll find there includes the OM-6.7 image, source code, a
> README and the various resources it uses (.so's, libs, fonts, icons,
> help-files, tutorials, other).
>
> This beta is not prepared to be installed anywhere, only to be run from
> inside the directory where you unpack it (type ./OM_6.7_beta_4 ... ).
> Plan is to make an installable version once the dust settles some.
>
> Theres one thing which needs installing to work however, the music-fonts
> used in the various editors and factories etc.  Theres an .rpm here:
>
>   http://forge.ircam.fr/p/OM6/downloads/get/omfonts-1.0-1.noarch.rpm.zip
>
> - which hopefully takes care of the fonts (theyre also available for
> manual install in the tarball).  The .rpm installs them (4 .ttf-files)
> inside its own folder /usr/share/fonts/omfonts/*
>
> The present version uses JACK for audio + midi I/O, and will try to
> start a JACK server if its not already running.
>
> To get any sound from the usual midi-ports, the linux-port uses
> libfluidsynth, and attempts to load one of the standard soundfonts into
> it.  However you should be able to route midi-output to any client you
> prefer (with jack-midi support).
>
> Thanks for any feedback.
>
> Cheers,
>
> -anders
>
>
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist



From anders.vinjar at bek.no  Mon Oct 28 14:35:04 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Mon, 28 Oct 2013 22:35:04 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	(Kjetil Matheussen's message of "Mon, 28 Oct 2013 21:42:51 +0100")
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
Message-ID: <87k3gxqdtj.fsf@notam02.no>

Hi Kjetil, thanks alot for testing, and for bug-reports!

    K> yum install fluidsynth-libs.i686
    K> yum install jack-audio-connection-kit.i686

They (32-bit versions of libjack + libfluidsynth) should be loaded from
the provided resources-folder if theyre not already installed.

Did you get any startup-messages about missing libs or wrong types etc?

    K> Loading a sound using the Class->Audio->SOUND object causes a segfault
    K> for me though:

Right.  This is a known bug when zooming in or displaying short sounds.
Ill fix that (temporarily, so it doesnt break at least) for now, and put
out a new build.

The patch-file below makes a temporary fix.  To use the patch just save
it inside the OM_6.7_**/patches/ dir and restart (or load it in the
running program):

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sound-draw-patch-1.lisp
Type: application/octet-stream
Size: 3098 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20131028/515dcba3/attachment.obj>
-------------- next part --------------

-anders

From rm at seid-online.de  Mon Oct 28 14:42:39 2013
From: rm at seid-online.de (Ralf Mattes)
Date: Mon, 28 Oct 2013 22:42:39 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <874n81p71v.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
Message-ID: <20131028214239.GA13240@seid-online.de>

On Mon, Oct 28, 2013 at 07:46:36PM +0100, anders.vinjar at bek.no wrote:
> Hi all.
> 
> Ive been working on a linux-port of IRCAMs OpenMusic lately, and think
> its approaching a useful state now.
> 
> I would very much appreciate it if some of the brave ones out there did
> some testing and sent me feedback:
> 
>   http://forge.ircam.fr/p/OM6/downloads/label/421/

Where is it? For me this webpage only shows omfonts-1.0-1.noarch.rpm.zip

Cheers, Ralf Mattes




From anders.vinjar at bek.no  Mon Oct 28 15:03:14 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Mon, 28 Oct 2013 23:03:14 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <87k3gxqdtj.fsf@notam02.no> (anders vinjar's message of "Mon, 28
	Oct 2013 22:35:04 +0100")
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
Message-ID: <878uxdqcil.fsf@notam02.no>

    a> Right.  This is a known bug when zooming in or displaying short sounds.

Should be fixed in the new one i just uploaded.



From anders.vinjar at bek.no  Mon Oct 28 15:04:37 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Mon, 28 Oct 2013 23:04:37 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <20131028214239.GA13240@seid-online.de> (Ralf Mattes's message of
	"Mon, 28 Oct 2013 22:42:39 +0100")
References: <874n81p71v.fsf@notam02.no> <20131028214239.GA13240@seid-online.de>
Message-ID: <874n81qcga.fsf@notam02.no>


    >> http://forge.ircam.fr/p/OM6/downloads/label/421/

    R> Where is it? For me this webpage only shows omfonts-1.0-1.noarch.rpm.zip

Sorry, was just replacing with a fix for the bug Kjetil found.  Its
there now.

Cheers,

-anders



From dlphillips at woh.rr.com  Tue Oct 29 07:23:20 2013
From: dlphillips at woh.rr.com (Dave Phillips)
Date: Tue, 29 Oct 2013 10:23:20 -0400
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <874n81p71v.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
Message-ID: <526FC4D8.30003@woh.rr.com>

Greetings,

Okay, here are some random impressions.

It's amazing. All props to the makers of former Linux versions of OM, 
but this version is already far ahead of previous work. AFAICT, in the 
little tests I've done so far, this port is usable and relatively 
stable. I tested some of the Tutorial patches, had some crashes 
(graphics issues, IIRC), I'll send details later.

Any chance we'll get the OM2Csound library ? (I had to ask. :)

Lots of xruns with JACK on my desktop box, not so many on the laptop. 
The desktop has an M-Audio Delta 66, the laptop uses its built-in 
hda_intel chipset. I need to play with settings, I'm sure.

Graphics updates are sometimes slow, especially with some click & drag 
moves. Both systems here have nVidia GPUs.

I know I have enough to get into with OM, but I'm curious: Is PWGL for 
Linux on anyone's roadmap ?

I had only a little time to work with the IRCAM docs and the port, I'll 
get some more time into it today. Busy week here.

Great work, Anders !

Best,

dp



From anders.vinjar at bek.no  Tue Oct 29 09:48:40 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Tue, 29 Oct 2013 17:48:40 +0100
Subject: [CM] linux-port of OpenMusic
References: <874n81p71v.fsf@notam02.no> <526FC4D8.30003@woh.rr.com>
Message-ID: <87r4b4kopj.fsf@notam02.no>

Hi Dave, thanks for reports and feedback!

    D> Any chance we'll get the OM2Csound library ? (I had to ask. :)

If its not part of the included libs its download-able from IRCAM
(http://forumnet.ircam.fr/product/openmusic-libraries/?lang=en).

After unzipping the lib, you can add it as an 'external' lib
(Windows->Library, and from the file-menu choose "Add remote user
library").  Or install it as a default lib in your OM (you'll find
how-tos in the docs).

There shouldnt be any real issues - lisp being lisp - afaik the
csound-thing does its work running an external csound-command in a
shell.  But please tell me what you find.

Just checked, the library loads ok at least.  The version you download
has a typo in one file-name, after unzipping, rename "OM2Csound.lisp" ->
"OM2CSound.lisp" (same as part of folder-name).

    D> Lots of xruns with JACK on my desktop box, not so many on the laptop. 
    D> The desktop has an M-Audio Delta 66, the laptop uses its built-in 
    D> hda_intel chipset. I need to play with settings, I'm sure.

    D> Graphics updates are sometimes slow, especially with some click & drag 
    D> moves. Both systems here have nVidia GPUs.

Well, OM is a composition tool, and a quite graphic-intense thing.
Depending on what you do, your cpu, multiprocessing etc, performance
will vary quite much.  If you observe some patterns in the behavior
please tell me.

Amongst the cool things is the callbacks for the jack-client (both audio
and midi) is programmed directly in lisp, and dynamically changeable on
the fly.  This could make a great tool for playing with various ways of
esp. event-handling.

Btw. ive setup the lisp-based jack-client to be independent of OM, and
it could be useful by itself.

    D> I know I have enough to get into with OM, but I'm curious: Is
    D> PWGL for Linux on anyone's roadmap ?

No idea.  Afaik the pwgl-sources arent gpl or similar, and dont seem to
be available from the devs.

    D> Great work, Anders !

Thanks.  Please continue sending issues, questions, especially
bug-reports etc.  I guess there will be new builds out on the server
quite often, as bugs pop up (and i get some time to fix them).

IRCAM have asked me to come to the forum-workshop on nov. 20th to
present the linux-port, and aim is to have a stable release by then.

Cheers.

-anders



From anders.vinjar at bek.no  Tue Oct 29 10:06:36 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Tue, 29 Oct 2013 18:06:36 +0100
Subject: [CM] linux-port of OpenMusic
References: <874n81p71v.fsf@notam02.no> <526FC4D8.30003@woh.rr.com>
Message-ID: <87iowgknvn.fsf@notam02.no>


    D> Any chance we'll get the OM2Csound library ? (I had to ask. :)

btw, one of the things id really like to do is finding good ways to use
CLM/Sndlib and CM together with this package.

CM loads fine just using the normal incantations.

CLM/sndlib needs some adjustments to the ffi-code to use CFFI
(preferably, or else lispworks FLI) to get up to speed, but there are
already about a dozen variants of the same ffi-code in sndlib2clm.lisp
already, so this should be possible (im sure Bill S., if he reads this,
gets a strange smile on his face now...)

-anders



From k.s.matheussen at gmail.com  Tue Oct 29 11:59:59 2013
From: k.s.matheussen at gmail.com (Kjetil Matheussen)
Date: Tue, 29 Oct 2013 19:59:59 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <87k3gxqdtj.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
Message-ID: <CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>

On Mon, Oct 28, 2013 at 10:35 PM,  <anders.vinjar at bek.no> wrote:
> Hi Kjetil, thanks alot for testing, and for bug-reports!
>
>     K> yum install fluidsynth-libs.i686
>     K> yum install jack-audio-connection-kit.i686
>
> They (32-bit versions of libjack + libfluidsynth) should be loaded from
> the provided resources-folder if theyre not already installed.
>
> Did you get any startup-messages about missing libs or wrong types etc?
>

Yes, I get a message that libjack couldn't be loaded:

[kjetil at ttlush OM_6.7_beta_4]$ ./OM_6.7_beta_4
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
Warning: G-domain : Gtk, level 16: Unable to locate theme engine in
module_path: "clearlooks",
"could not load foreign-library libjack" Wrote error log to
/home/kjetil/logs/OpenMusic/OM-6-7_beta_4-Log_2013-10-29_19-54-19 at
2013/10/29 19:54:19


I also tried to set LD_LIBRARY_PATH to the resources directory with
the jack libraries, but that
didn't help. I guess the problem is missing libopus:


[kjetil at ttlush OM_6.7_beta_4]$ ldd -r resources/lib/linux/libjack.so
linux-gate.so.1 =>  (0xf7756000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf76bc000)
libcelt0.so.2 => /lib/libcelt0.so.2 (0xf76a4000)
libopus.so.0 => not found
librt.so.1 => /lib/librt.so.1 (0xf769b000)
libdl.so.2 => /lib/libdl.so.2 (0xf7695000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf75a9000)
libm.so.6 => /lib/libm.so.6 (0xf757e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7561000)
libc.so.6 => /lib/libc.so.6 (0xf73af000)
/lib/ld-linux.so.2 (0x4e6d5000)



[kjetil at ttlush OM_6.7_beta_4]$ more
/home/kjetil/logs/OpenMusic/OM-6-7_beta_4-Log_2013-10-29_19-54-19

===   Log at 2013/10/29 19:54:19  ===

An error occured : Foreign function
CL-JACK::|%cffi-foreign-function/JACK-CLIENT-OPEN| trying to call to
unresolved external function "jack_client_open".

PRODUCT CONFIGURATION:

  LispWorks 6.1.1

Process name: /gammelhd/newstuff/temp/OM_6.7_beta_4/./OM_6.7_beta_4
   ID: 28387    Started at: 2013/10/29 19:54:10

Save history:

1: lispworks-6-1-0-0-x86-linux-release-base
Saved by davef as lispworks-6-1-0-0-x86-linux-release-base, at 03 Nov 2011 13:25

2: lispworks-6-1-0-0-x86-linux-release-gtk-shaken
Saved by davef as lispworks-6-1-0-0-x86-linux-release-gtk-shaken, at
03 Nov 2011 14:00

3: lispworks-6-1-0-0-x86-linux-release-gtk-shaken
Saved by davef as lispworks-6-1-0-x86-linux, at 10 Jan 2012 17:32
LispWorks 6.1.0

4: lispworks-6-1-1-0-x86-linux-release-gtk-shaken
Saved by andersvi as lw-noenv-6.1, at 06 Feb 2013 15:32

5: lispworks-6-1-1-0-x86-linux-release-gtk-shaken
Saved by andersvi as OM_6.7_beta_4, at 28 Oct 2013 14:34
Saved by DELIVER

Loaded Modules:  "delivery", "delivery-keywords", "CLENI",
  "CL-FLUIDSYNTH", "CL-JACK", "OSC", "comm", "asdf", "CFFI", "ASDF"

Public patches:  PATCH-ITSELF 1.5, CAPI-GTK 1.8, CAPI 1.23,
  COMPILER 1.5, EDITOR 1.14, FULL 1.7, MP 1.10, SYSTEM32 1.3,
  SYSTEM 1.17, COMM 1.5, DELIVERY 1.2, ORACLE 1.0, CORBA-SUPPORT 1.0

Foreign modules:
  #<FLI::INTERNAL-MODULE :LISP : exports = 0>
  #<FLI::INTERNAL-MODULE :CALLBACKS : exports = 0>
  #<FLI::EXTERNAL-MODULE "-lGL"  {/lib/libGL.so.1}: handle =
#xF633FB40; exports = 0>
  #<FLI::EXTERNAL-MODULE "-lGLU"  {/lib/libGLU.so.1}: handle =
#xF633E668; exports = 0>
  #<FLI::EXTERNAL-MODULE "-lgthread-2.0"  {/lib/libgthread-2.0.so.0}:
handle = #xF63004A0; exports = 15>
  #<FLI::EXTERNAL-MODULE "-lgtk-x11-2.0"  {/lib/libgtk-x11-2.0.so.0}:
handle = #xF6300FF0; exports = 152>
  #<FLI::EXTERNAL-MODULE |libsndfile|::LIBSNDFILE
{/lib/libsndfile.so.1}: handle = #xF631F6E8; exports = 0>
  #<FLI::EXTERNAL-MODULE CL-JACK::LIBJACK  : handle = #x00000000; exports = 0>

Signal Handlers
2       SYSTEM::SIGINT-HANDLER
10      MP::CALL-BREAK-OF-MP
12      MP::PANIC
13      SYSTEM::THE-NULL-FUNCTION
17      SYSTEM::GET-CHILDREN-INF
29      SYSTEM::THE-NULL-FUNCTION

HOST CONFIGURATION:

  ttlush.localdomain (x86_64), Linux 3.9.10-100.fc17.x86_64
  Fedora release 17 (Beefy Miracle)
  Kernel \r on an \m (\l)

LWSerialNumber: LWPRO0610021302309345

Site: Unknown

GTK+ library versions:
  glib 2.32.4
  pango 1.30.0
  gtk 2.24.13
  gdk-pixbuf 2.26.1
  atk 2.4.0
  cairo 1.10.2

Backtrace:
#<The COMMON-LISP-USER package, 74/128 internal, 8/16 external>
#<MP:PROCESS Name "Initial delivery process" Priority 0 State "Running">



Call to OM-API::OM-DEBUGGER-HOOK {offset 354}
  CONDITION                 : #<SIMPLE-ERROR 200D297B>
  OM-API::OLD-DEBUGGER-HOOK : :DONT-KNOW
  LOG                       : T
  OM-API::LOGPATH           :
#P"/home/kjetil/logs/OpenMusic/OM-6-7_beta_4-Log_2013-10-29_19-54-19"

Binding frame:
  *DEBUGGER-HOOK* : OM-API::OM-DEBUGGER-HOOK

Tag environment contour:
Function environment contour
Block environment contour: (CL-JACK::CL-JACK-INIT-EVERYTHING)
Variable environment contour: ()
Call to DBG::DEBUG1 {offset 224}
  DBG::DATUM     : #<SIMPLE-ERROR 200D297B>
  DBG::ARGUMENTS : NIL

Binding frame:
  MP::*PROCESSING-INTERRUPTS* : NIL
  *EVALHOOK*                  : NIL

Call to INVOKE-DEBUGGER {offset 213}
  CONDITION : #<SIMPLE-ERROR 200D297B>

Binding frame:
  CONDITIONS::*BROKEN-ON-SIGNALS* : NIL

Call to ERROR {offset 67}
  SYSTEM::ESTRING : "Foreign function ~S trying to call to unresolved
external function ~S."
  SYSTEM::EARGS   :
(CL-JACK::|%cffi-foreign-function/JACK-CLIENT-OPEN|
"jack_client_open")

Call to CL-JACK::|%cffi-foreign-function/JACK-CLIENT-OPEN| {offset 354}
  #:G155240        : #<Pointer to type :BYTE = #xF6336338>
  #:G155241        : 0
  #:G155242        : 0
  SYMBOL           : #<FLI::EXTERNAL-SYMBOL "jack_client_open" : addr
= #x00000000>
  FLI::RAW-ADDRESS : :DONT-KNOW

Catch frame: #<Unbound Marker>

Call to CL-JACK::JACK-CLIENT-OPEN {offset 113}
  CL-JACK::NAME      : "CLJack"
  CL-JACK::OPTION    : 0
  CL-JACK::STATUS    : 0
  DBG::G             : #<Pointer to type :BYTE = #xF6336338>
  DBG::PARAM         : T
  DBG::|m-v-b-&rest| : :DONT-KNOW

Call to CL-JACK::CL-JACK-INIT-MIDI {offset 385}

Interpreted call to CL-JACK::CL-JACK-INIT-EVERYTHING:

Block environment contour: (INIT-OM)
Tag environment contour:
Function environment contour
Variable environment contour: ()
Call to OM-API:OM-INIT-FUNCALL {offset 160}
  DBG::G    : (|libsndfile|::INIT-LIBSNDFILE
CL-JACK::CL-JACK-INIT-EVERYTHING
CL-FLUIDSYNTH::CL-FLUID-INIT-FLUIDSYNTH
|OpenMusic|::INIT-OM-COLOR-VARS |OpenMusic|::INIT-OM-FONTS-VARS
|OpenMusic|::INIT-CURS |OpenM
usic|::INIT-ICON-FOLDER |OpenMusic|::INIT-ALL-PICT
|OpenMusic|::INIT-OMLIB-DIRECTORY |OpenMusic|::INIT-APP-MENU
|OpenMusic|::INIT-PREFERENCES |OpenMusic|::INIT-OM-PREF-COLOR
|OpenMusic|::INIT-D&D-HANDLER |OpenMu
sic|::SET-REF-DIR |OpenMusic|::INIT-MUSIC-PICT
|OpenMusic|::CREATE-SCORE-CURSORS |OpenMusic|::INIT-MIDISETUP
|OpenMusic|::INIT-JACK-MIDI-PLAYER |OpenMusic|::INIT-CERCLE-CURSOR
|OpenMusic|::INIT-JACK-AUDIO-PLAYER
 |OpenMusic|::INIT-MPLAYER-APP |OpenMusic|::INIT-SDIF-LIB)
  DBG::G    : (CL-JACK::CL-JACK-INIT-EVERYTHING
CL-FLUIDSYNTH::CL-FLUID-INIT-FLUIDSYNTH
|OpenMusic|::INIT-OM-COLOR-VARS |OpenMusic|::INIT-OM-FONTS-VARS
|OpenMusic|::INIT-CURS |OpenMusic|::INIT-ICON-FOLDER |OpenM
usic|::INIT-ALL-PICT |OpenMusic|::INIT-OMLIB-DIRECTORY
|OpenMusic|::INIT-APP-MENU |OpenMusic|::INIT-PREFERENCES
|OpenMusic|::INIT-OM-PREF-COLOR |OpenMusic|::INIT-D&D-HANDLER
|OpenMusic|::SET-REF-DIR |OpenMusic|:
:INIT-MUSIC-PICT |OpenMusic|::CREATE-SCORE-CURSORS
|OpenMusic|::INIT-MIDISETUP |OpenMusic|::INIT-JACK-MIDI-PLAYER
|OpenMusic|::INIT-CERCLE-CURSOR |OpenMusic|::INIT-JACK-AUDIO-PLAYER
|OpenMusic|::INIT-MPLAYER-APP
 |OpenMusic|::INIT-SDIF-LIB)
  OM-API::X : CL-JACK::CL-JACK-INIT-EVERYTHING

Interpreted call to INIT-OM:

Block environment contour:
Tag environment contour:
Function environment contour
Variable environment contour: ()
Call to DELIVERY::MAYBE-RYB-TOP-LEVEL {offset 242}
  DELIVERY::OLD-RESTART  {Closed} : INIT-OM

Catch frame: MP::PROCESS-TAG

Catch frame: (MP::PROCESS-SG-FUNCTION . 1)

Catch frame: (MP::PROCESS-SG-FUNCTION . 1)

Binding frame:
  MP:*CURRENT-PROCESS* : NIL

Binding frame:
  MP::*ACTIONS-AFTER-SLEEPING* : NIL

Binding frame:
  MP::*ACTIONS-BEFORE-SLEEPING* : NIL

Binding frame:
  SYSTEM::*READER-STATE* : #<SYSTEM::READER-STATE In 0 out 19 201C3F6F>

Binding frame:
  *PACKAGE* : #<The COMMON-LISP-USER package, 74/128 internal, 8/16 external>

Binding frame:
  SYSTEM::*SELECT-DUMMY* : NIL

Binding frame:
  LWGTK::*GDK-LOCK-DEPTH* : 1

Binding frame:
  EDITOR::*CURRENT-BUFFER* : NIL

Binding frame:
  EDITOR::*CURRENT-WINDOW* : NIL

Binding frame:
  EDITOR::*EDITOR-STATE* : NIL

Binding frame:
  EDITOR::*EDITOR-INPUT-STYLE* : #S(EDITOR:EDITOR-INPUT-STYLE
:KEY-BINDINGS #<EDITOR::KEY-TABLE #<EQUALP Hash Table{343} 20E6485F> 1
342> :DELETE-SELECTION-MODE NIL :LOGICAL-CHARACTERS #<EQUALP Hash
Table{22} 20
E3568F> :EXECUTE-MODE #<EDITOR::MODE-OBJECT "Execute" 211A71D3>
:ECHO-MODE #<EDITOR::MODE-OBJECT "Echo Area" 211A6D6B> :PLIST NIL
:INTERRUPT-KEYS (#S(SYSTEM::GESTURE-SPEC :DATA 103 :MODIFIERS 2)
#S(SYSTEM::GESTU
RE-SPEC :DATA 71 :MODIFIERS 2)) :STYLE :EMACS :POINT-ALWAYS-VISIBLE T
:USE-FACE-TO-FULL-WIDTH-P T)

Binding frame:
  CAPI::*USE-ACCELERATORS* : T

Catch frame: #:|progv-cathcer240428|

Call to MP::PROCESS-SG-FUNCTION {offset 555}
  MP::STACK-ARG : 0
  MP::SYMBOLS   : NIL
  VALUES        : NIL

Call to SYSTEM::%%FIRST-CALL-TO-STACK {offset 41}

SYSTEM::%%FIRST-CALL-TO-STACK

 Generation 0:  Total Size 1190K, Allocated 463K, Free 718K
          Segment 20090128: Total Size 507K, Allocated 325K, Free 178K
                    minimum free space 64K,
                      Awaiting promotion = 0K, sweeps before promotion =10
          Segment 245554F8: Total Size 682K, Allocated 137K, Free 540K
                    minimum free space 0K,
                      Awaiting promotion = 8K, sweeps before promotion =2
 Generation 1:  Total Size 948K, Allocated 745K, Free 190K
          Segment 2070F0C0: Total Size 68K, Allocated 15K, Free 48K
                    minimum free space 3K,
                      Awaiting promotion = 0K, sweeps before promotion =4
          Segment 1FF60000: Total Size 640K, Allocated 556K, Free 79K
                    minimum free space 0K, static
          Segment 200540A8: Total Size 240K, Allocated 173K, Free 62K
                    minimum free space 0K, static
 Generation 2:  Total Size 68K, Allocated 0K, Free 64K
          Segment 20F1C640: Total Size 68K, Allocated 0K, Free 64K
                    minimum free space 117K,
                      Awaiting promotion = 0K, sweeps before promotion =4
 Generation 3:  Total Size 69776K, Allocated 69636K, Free 128K
          Segment 2010F0C0: Total Size 6144K, Allocated 6139K, Free 0K
                    minimum free space 3K,
                      Awaiting promotion = 0K, sweeps before promotion =10
          Segment 20F2D6B8: Total Size 55455K, Allocated 55323K, Free 128K
                    minimum free space 0K,
                      Awaiting promotion = 0K, sweeps before promotion =10
          Segment 20720138: Total Size 8177K, Allocated 8173K, Free 0K
                    minimum free space 0K,
                      Awaiting promotion = 0K, sweeps before promotion =10

Total Size 72320K, Allocated 70846K, Free 1100K

++++++++++++++++++++++++++++++++++++++++



From anders.vinjar at bek.no  Tue Oct 29 13:03:24 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Tue, 29 Oct 2013 21:03:24 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
	(Kjetil Matheussen's message of "Tue, 29 Oct 2013 19:59:59 +0100")
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
Message-ID: <878uxbkfoz.fsf@notam02.no>

>>>>> "K" == Kjetil Matheussen <k.s.matheussen at gmail.com> writes:

    K> libopus.so.0 => not found

Dont know why this is used by the libjack.so sent along (its from the
standard fc-19 repo), but not on your system.

What does the one coming with your jack-audio-connection-kit.i686 say?

-anders



From k.s.matheussen at gmail.com  Tue Oct 29 14:06:33 2013
From: k.s.matheussen at gmail.com (Kjetil Matheussen)
Date: Tue, 29 Oct 2013 22:06:33 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <878uxbkfoz.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
	<878uxbkfoz.fsf@notam02.no>
Message-ID: <CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>

On Tue, Oct 29, 2013 at 9:03 PM,  <anders.vinjar at bek.no> wrote:
>>>>>> "K" == Kjetil Matheussen <k.s.matheussen at gmail.com> writes:
>
>     K> libopus.so.0 => not found
>
> Dont know why this is used by the libjack.so sent along (its from the
> standard fc-19 repo), but not on your system.
>
> What does the one coming with your jack-audio-connection-kit.i686 say?
>

[root at ttlush kjetil]# ldd -r /usr/lib/libjack.so.0
linux-gate.so.1 =>  (0xf77d4000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf773b000)
libcelt0.so.2 => /lib/libcelt0.so.2 (0xf7723000)
librt.so.1 => /lib/librt.so.1 (0xf771a000)
libdl.so.2 => /lib/libdl.so.2 (0xf7715000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0xf7628000)
libm.so.6 => /lib/libm.so.6 (0xf75fd000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf75e0000)
libc.so.6 => /lib/libc.so.6 (0xf742e000)
/lib/ld-linux.so.2 (0x4e6d5000)

Maybe it's a good idea to use static versions of libcelt and/or libopus
in the libjack included with open music.



From anders.vinjar at bek.no  Tue Oct 29 14:14:22 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Tue, 29 Oct 2013 22:14:22 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>
	(Kjetil Matheussen's message of "Tue, 29 Oct 2013 22:06:33 +0100")
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
	<878uxbkfoz.fsf@notam02.no>
	<CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>
Message-ID: <87vc0fixu9.fsf@notam02.no>

>>>>> "K" == Kjetil Matheussen <k.s.matheussen at gmail.com> writes:

    K> Maybe it's a good idea to use static versions of libcelt and/or libopus
    K> in the libjack included with open music.

Fernando sent me some suggestions about this, and it seems the good idea
is to make users install the .so's through their various dists.

Ill change that on thursday :-)

Cheers,

-anders



From rm at seid-online.de  Tue Oct 29 14:44:26 2013
From: rm at seid-online.de (Ralf Mattes)
Date: Tue, 29 Oct 2013 22:44:26 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <87vc0fixu9.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
	<878uxbkfoz.fsf@notam02.no>
	<CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>
	<87vc0fixu9.fsf@notam02.no>
Message-ID: <20131029214426.GA18018@seid-online.de>

On Tue, Oct 29, 2013 at 10:14:22PM +0100, anders.vinjar at bek.no wrote:
> >>>>> "K" == Kjetil Matheussen <k.s.matheussen at gmail.com> writes:
> 
>     K> Maybe it's a good idea to use static versions of libcelt and/or libopus
>     K> in the libjack included with open music.
> 
> Fernando sent me some suggestions about this, and it seems the good idea
> is to make users install the .so's through their various dists.

I think that's not really a viable solution. At least libcelt isn't even 
currently available in Debian stable/testing.

I don't see a reason to include a _static_ version of libcelt/libopus. Since
you distribute libjack, why not distribute libcelt/libopus?

BTW, any chance to get a 64bit version? I'm not shure a 32bit libjack will play
nicely with a 64bit jackd.

 Thanks a lot, RalfD



From bil at ccrma.Stanford.EDU  Tue Oct 29 14:56:15 2013
From: bil at ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Tue, 29 Oct 2013 14:56:15 -0700
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <87iowgknvn.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no> <526FC4D8.30003@woh.rr.com>
	<87iowgknvn.fsf@notam02.no>
Message-ID: <20131029215119.M26291@ccrma.Stanford.EDU>

Besides sndlib2clm.lisp, I think you would need to deal with ffi.lisp
and defins.lisp, but it's been a long time since I looked at this code.
I vaguely remember that the CFFI problem was passing float and
int arrays to/from C (in defins.lisp?). 



From anders.vinjar at bek.no  Tue Oct 29 15:17:09 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Tue, 29 Oct 2013 23:17:09 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <20131029214426.GA18018@seid-online.de> (Ralf Mattes's message of
	"Tue, 29 Oct 2013 22:44:26 +0100")
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
	<878uxbkfoz.fsf@notam02.no>
	<CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>
	<87vc0fixu9.fsf@notam02.no> <20131029214426.GA18018@seid-online.de>
Message-ID: <87y55bhgd6.fsf@notam02.no>


    R> I think that's not really a viable solution. At least libcelt
    R> isn't even currently available in Debian stable/testing.

Then i guess your libjack doesnt need it?

The jack-api in use in OM is very simple, and doesnt rely on anything
outside jack.h

    R> BTW, any chance to get a 64bit version? 

If you provide me with a 'enterprise'-license for lw (= 3 times the
price of the 'pro'-license :-/ )

    R> I'm not shure a 32bit libjack will play nicely with a 64bit
    R> jackd.

It usually does.  What troubles do you see?



From anders.vinjar at bek.no  Tue Oct 29 15:25:52 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Tue, 29 Oct 2013 23:25:52 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <20131029215119.M26291@ccrma.Stanford.EDU> (Bill Schottstaedt's
	message of "Tue, 29 Oct 2013 14:56:15 -0700")
References: <874n81p71v.fsf@notam02.no> <526FC4D8.30003@woh.rr.com>
	<87iowgknvn.fsf@notam02.no> <20131029215119.M26291@ccrma.Stanford.EDU>
Message-ID: <87txfzhfyn.fsf@notam02.no>

>>>>> "B" == Bill Schottstaedt <bil at ccrma.Stanford.EDU> writes:

    B> I vaguely remember that the CFFI problem was passing float and
    B> int arrays to/from C (in defins.lisp?).

Hi Bill.

Im not too sure, but dont think that should be a problem anymore.  Afaik
CFFI has had support for passing of arrays for some time.

I can look into that later (end of november?), if noone gets there
before me :-)

-anders



From rm at seid-online.de  Tue Oct 29 15:40:16 2013
From: rm at seid-online.de (Ralf Mattes)
Date: Tue, 29 Oct 2013 23:40:16 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <87y55bhgd6.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
	<878uxbkfoz.fsf@notam02.no>
	<CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>
	<87vc0fixu9.fsf@notam02.no> <20131029214426.GA18018@seid-online.de>
	<87y55bhgd6.fsf@notam02.no>
Message-ID: <20131029224016.GB18018@seid-online.de>

On Tue, Oct 29, 2013 at 11:17:09PM +0100, anders.vinjar at bek.no wrote:
> 
>     R> I think that's not really a viable solution. At least libcelt
>     R> isn't even currently available in Debian stable/testing.
> 
> Then i guess your libjack doesnt need it?

This is the Debian-provided libjack:

 ldd /usr/lib/x86_64-linux-gnu/libjack.so.0
	linux-vdso.so.1 (0x00007fff6afe8000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec6650a000)
	libopus.so.0 => /usr/lib/libopus.so.0 (0x00007fec662c3000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fec660ba000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec65eb6000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fec65bb3000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec658b4000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fec6569e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec652f2000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fec669c6000)

> The jack-api in use in OM is very simple, and doesnt rely on anything
> outside jack.h
> 
>     R> BTW, any chance to get a 64bit version? 
> 
> If you provide me with a 'enterprise'-license for lw (= 3 times the
> price of the 'pro'-license :-/ )

Yeah, tell me. I was _almost: buying a LW Licence, until I saw that huge price
tag on the 64bit version. 64bit == Enterpise, that's so 1990ish ;-)
 
>     R> I'm not shure a 32bit libjack will play nicely with a 64bit
>     R> jackd.
> 
> It usually does.  What troubles do you see?

None, since I couldn't get OM to run without libcelt. I just speculated, since 
libjack and jack need to work as a pair (i.e. jackd and libjack need to match) 
and from toying with jack on ARN I know that there are some struct packing issues.
 
Cheers, RalfD
 
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist



From nando at ccrma.Stanford.EDU  Tue Oct 29 19:24:16 2013
From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano)
Date: Tue, 29 Oct 2013 19:24:16 -0700
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <20131029224016.GB18018@seid-online.de>
References: <874n81p71v.fsf@notam02.no>	<CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>	<87k3gxqdtj.fsf@notam02.no>	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>	<878uxbkfoz.fsf@notam02.no>	<CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>	<87vc0fixu9.fsf@notam02.no>
	<20131029214426.GA18018@seid-online.de>	<87y55bhgd6.fsf@notam02.no>
	<20131029224016.GB18018@seid-online.de>
Message-ID: <52706DD0.6010507@localhost>

On 10/29/2013 03:40 PM, Ralf Mattes wrote:
> On Tue, Oct 29, 2013 at 11:17:09PM +0100, anders.vinjar at bek.no wrote:
>>
>>      R> I think that's not really a viable solution. At least libcelt
>>      R> isn't even currently available in Debian stable/testing.
>>
>> Then i guess your libjack doesnt need it?
>
> This is the Debian-provided libjack:
>
>   ldd /usr/lib/x86_64-linux-gnu/libjack.so.0
> 	linux-vdso.so.1 (0x00007fff6afe8000)
> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec6650a000)
> 	libopus.so.0 => /usr/lib/libopus.so.0 (0x00007fec662c3000)
> 	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fec660ba000)
> 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec65eb6000)
> 	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fec65bb3000)
> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec658b4000)
> 	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fec6569e000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec652f2000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007fec669c6000)
>
>> The jack-api in use in OM is very simple, and doesnt rely on anything
>> outside jack.h

Then dynamically linking against the native build of libjack should be 
more than enough, no need to package .so binaries which will always lead 
to problems (for example, libcelt is required by a certain build of 
libjack but not others - if you use the native libjack the distribution 
will take care of the proper library dependencies).

>>      R> BTW, any chance to get a 64bit version?
>>
>> If you provide me with a 'enterprise'-license for lw (= 3 times the
>> price of the 'pro'-license :-/ )
>
> Yeah, tell me. I was _almost: buying a LW Licence, until I saw that huge price
> tag on the 64bit version. 64bit == Enterpise, that's so 1990ish ;-)
>
>>      R> I'm not shure a 32bit libjack will play nicely with a 64bit
>>      R> jackd.
>>
>> It usually does.  What troubles do you see?
>
> None, since I couldn't get OM to run without libcelt. I just speculated, since
> libjack and jack need to work as a pair (i.e. jackd and libjack need to match)
> and from toying with jack on ARN I know that there are some struct packing issues.

Jack needs to be compiled with the -DJACK_32_64 option (at least jack2 
does - there's also a compile flag but I forget the name), that creates 
structures that can be accessed from the 32 and 64 worlds without 
compatibility problems. I needed to do that for Planet CCRMA when chuck 
was 32 bit only and our workstations were running 64 bit OSs. A Jack 
that is built with that option will work with 32 bit apps on a 64 bit 
environment.

-- Fernando



From rm at seid-online.de  Tue Oct 29 20:28:09 2013
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 30 Oct 2013 04:28:09 +0100
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <52706DD0.6010507@localhost>
References: <CAC6niEKtE1fmWvAO9f_ALAFcn=4v+=++wmdi4riUOgViydsyRQ@mail.gmail.com>
	<87k3gxqdtj.fsf@notam02.no>
	<CAC6niEKWtr0moaFQx835oLJz9zQa4xGhFV7Gx+auSS-se9q0hA@mail.gmail.com>
	<878uxbkfoz.fsf@notam02.no>
	<CAC6niEL+oU2_6raJu5edOc3XNa2bAVZ2NUazxVUbTe6xUStGYg@mail.gmail.com>
	<87vc0fixu9.fsf@notam02.no> <20131029214426.GA18018@seid-online.de>
	<87y55bhgd6.fsf@notam02.no> <20131029224016.GB18018@seid-online.de>
	<52706DD0.6010507@localhost>
Message-ID: <20131030032809.GA18394@seid-online.de>

On Tue, Oct 29, 2013 at 07:24:16PM -0700, Fernando Lopez-Lezcano wrote:
> >On Tue, Oct 29, 2013 at 11:17:09PM +0100, anders.vinjar at bek.no wrote:
> >>The jack-api in use in OM is very simple, and doesnt rely on anything
> >>outside jack.h
> 
> Then dynamically linking against the native build of libjack should
> be more than enough, no need to package .so binaries which will
> always lead to problems (for example, libcelt is required by a
> certain build of libjack but not others - if you use the native
> libjack the distribution will take care of the proper library
> dependencies).

Yes, use the distribution if possible at all.

> >>     R> I'm not shure a 32bit libjack will play nicely with a 64bit
> >>     R> jackd.
> >>
> >>It usually does.  What troubles do you see?
> >
> >None, since I couldn't get OM to run without libcelt. I just speculated, since
> >libjack and jack need to work as a pair (i.e. jackd and libjack need to match)
> >and from toying with jack on ARN I know that there are some struct packing issues.
> 
> Jack needs to be compiled with the -DJACK_32_64 option (at least
> jack2 does - there's also a compile flag but I forget the name),
> that creates structures that can be accessed from the 32 and 64
> worlds without compatibility problems. I needed to do that for
> Planet CCRMA when chuck was 32 bit only and our workstations were
> running 64 bit OSs. A Jack that is built with that option will work
> with 32 bit apps on a 64 bit environment.

Ah - I see. Unfortunately, Debian dropped this flag quite a while ago.
>From the changelog: "Drop mixed 32/64bit builds. Will be replaced by multiarch"
Hmm, I'm not shure this was a good idea ...

 Thanks a lot 
 
 RalfD

> -- Fernando



From dlphillips at woh.rr.com  Wed Oct 30 05:30:57 2013
From: dlphillips at woh.rr.com (Dave Phillips)
Date: Wed, 30 Oct 2013 08:30:57 -0400
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <874n81p71v.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no>
Message-ID: <5270FC01.8030804@woh.rr.com>

Greetings,

Made a simple patch, renamed it, OM crashed with this report :

**
Gtk:ERROR:/build/buildd/gtk+2.0-2.24.10/gtk/gtkcontainer.c:2763:IA__gtk_container_propagate_expose: 
assertion failed: (child->parent == GTK_WIDGET (container))

Error: Segmentation violation(11) [code 0] at 21918042
      {Offset 8 inside #<Function 
capi-gtk-library::lispworks-layout-widget-set-child-geometry 2191803A>}
eax       58 ; ebx A00F75B0 ; ecx 2061062C ; edx        1
esp 1CEFD5A4 ; ebp 1CEFD5AC ; esi       56 ; edi        0
   1 (abort) Return to event loop.
   2 Destroy interface "omwork" (of type editorwindow)

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other 
options.

OpenMusic 1 : 1 >


Ctrl-C gets me out of the loop, and the patch is renamed correctly - and 
works - when I restart. It's a simple calculator for a harmonic series, 
copied from this video :

http://www.youtube.com/watch?v=C_yo4Xgwo0w

The patch doesn't appear to cause any problems. Maybe LW doesn't get 
along with Xfce on Ubuntu 12.04 ?

Please advise if you need more information, I'm happy to help debug, 
though I'll need some pointers. It's been a while since I last worked 
with Common Lisp.

Best,

dp



From anders.vinjar at bek.no  Wed Oct 30 16:41:09 2013
From: anders.vinjar at bek.no (anders.vinjar at bek.no)
Date: Thu, 31 Oct 2013 00:41:09 +0100
Subject: [CM] linux-port of OpenMusic
References: <874n81p71v.fsf@notam02.no> <5270FC01.8030804@woh.rr.com>
Message-ID: <877gcu9vje.fsf@notam02.no>

>>>>> "D" == Dave Phillips:

    D> Greetings, Made a simple patch, renamed it, OM crashed with this
    D> report :

That on was a bit tricky.  Sorry to be of little or no help, but im only
able to ask questions atm:

You mean double-clicking the name, typing in a new name, then hit enter?
Or clicking on the workspace-background?

Exactly when (at which action) did it break?

Is it reproducable, ie, every time, only certain times, any pattern of
behavior?

-anders



From dlphillips at woh.rr.com  Wed Oct 30 17:55:15 2013
From: dlphillips at woh.rr.com (Dave Phillips)
Date: Wed, 30 Oct 2013 20:55:15 -0400
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <877gcu9vje.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no> <5270FC01.8030804@woh.rr.com>
	<877gcu9vje.fsf@notam02.no>
Message-ID: <5271AA73.1040202@woh.rr.com>

On 10/30/2013 07:41 PM, anders.vinjar at bek.no wrote:
>      D> Greetings, Made a simple patch, renamed it, OM crashed with this
>      D> report :
>
> That on was a bit tricky.  Sorry to be of little or no help, but im only
> able to ask questions atm:
>
> You mean double-clicking the name, typing in a new name, then hit enter?

That's it, and it is reproducible. I just tried on the second machine's 
installation, same result. However, I used the Lisp interface to recover 
from the error. OM proceeded as though nothing had happened.

I can also freeze the program by using the scroller/slider that Ubuntu 
imposed on its users. When I use it to scroll down an OM window it 
sometimes freezes the app. I'll generate a report for that one asap.

Sorry I'm not so detailed with the reports right now, I'm in the middle 
of teaching and prepping a performance for the weekend. But I'll keep 
working with it. I've been following various tutorial materials, lots of 
good stuff to work with.

Best,

dp



From dlphillips at woh.rr.com  Wed Oct 30 17:57:02 2013
From: dlphillips at woh.rr.com (Dave Phillips)
Date: Wed, 30 Oct 2013 20:57:02 -0400
Subject: [CM] linux-port of OpenMusic
In-Reply-To: <877gcu9vje.fsf@notam02.no>
References: <874n81p71v.fsf@notam02.no> <5270FC01.8030804@woh.rr.com>
	<877gcu9vje.fsf@notam02.no>
Message-ID: <5271AADE.1090002@woh.rr.com>

Greetings,

Btw, I also get truncated text of the last line in some displays. I'll 
post some screenshots tomorrow.

Best,

dp