incudine-devel — Development discussions

Re: [incudine-devel] can't open osc input on OSX

[Orm F. <orm...@se...>]

Hi Tito,

 I agree it's very frustrating. I'm well aware that it is not
incudine's fault and didn't intend to implicate that by any means.
Sorry in case it came across that way. I doubt, a report to Apple will
have any effect whatsoever but don't bother in the case of incudine as
I can work around it.

The reason it didn't come up earlier on my part: It's my first Apple
in 20 years. Although very minor it unfortunately is an indispensible
component in my current setup due to driver issues. It took me a very
long time meditating over whether I should even get it. After the
purchase I unfortunately immediately started to install sbcl and
incudine on it.

--
Orm

Am Freitag, den 21. Juni 2024 um 07:12:56 Uhr (+0200) schrieb Tito Latini:
> There is not a problem with the "incudine's osc implementation"
> but with "getaddrinfo+bind on OSX", or on your specific system.
> 
> Incudine uses getaddrinfo() since 2015. I get a report from
> Daniel and Orm after nine years. I can add a little workaround
> if getaddrinfo() doesn't work on OSX (really? why?).
> 
> Il giorno gio 20 giu 2024 alle ore 14:26 Orm Finnendahl <
> orm...@se...> ha scritto:
> 
> > Hi,
> >
> >  unfortunately I couldn't pinpoint the reason, incudine's osc
> > implementation doesn't work on OSX for input. I unsuccessfully tried
> > various ways to get bind working and I'm still not absolutely sure
> > this hasn't got to do with some sort of sandboxing on OSX's side. I
> > seemingly can't use debugging tools on the machine without getting an
> > Apple ID, which I don't want to do. But I found out that the OSC
> > package by Nik Gaffney (https://github.com/zzkt/osc) works on OSX. It
> > uses usocket, which uses sb-bsd-sockets. That could be a place to
> > start looking, but unfortunately it's a bit over my head to find out
> > what the code exactly does and why it works.
> >
> > I can build a thin compatibility layer to make my own code work on OSX
> > and can share it to anybody interested. AFAICT the OSC implementation
> > of Nik Gaffney's package doesn't support time tags. Nevertheless for
> > me this seems the best way to go at the moment although I reckon that
> > this is far from ideal.
> >
> > --
> > Orm
> >
> >
> > Am Donnerstag, den 13. Juni 2024 um 09:58:08 Uhr (+0200) schrieb Orm
> > Finnendahl:
> > > Am Donnerstag, den 13. Juni 2024 um 09:18:24 Uhr (+0200) schrieb Tito
> > Latini:
> > > > You get the message "Destination address required" from bind().
> > > > If OSC::*ADDRINFO-HINTS-FLAGS* is 0 (default), ask to Apple
> > > > because getaddrinfo() in Incudine follows the settings in
> > > >
> > > >
> > https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getaddrinfo.3.html
> > > >
> > > > See incudine/src/network/osc.c::32 (I presume AF_UNSPEC is
> > > > PF_UNSPEC on osx too) and BIND-STREAM-SOCKET in
> > > > incudine/src/network/osc.lisp::417.
> > >
> > >  :-(
> > >
> > > incudine.osc::*addrinfo-hints-flags* returns 0 on the Mac as you say.
> > >
> > > I'll try to investigate further as usocket works for input on the Mac
> > > and as far as I know unix sockets, usocket also has to issue a bind()
> > > someplace to accomplish that. Thanks for the info, I'll report back...
> > >
> > > --
> > > Orm
> > >
> > >
> > > _______________________________________________
> > > incudine-devel mailing list
> > > inc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/incudine-devel
> >
> >
> > _______________________________________________
> > incudine-devel mailing list
> > inc...@li...
> > https://lists.sourceforge.net/lists/listinfo/incudine-devel
> >


> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel

Re: [incudine-devel] can't open osc input on OSX

[Tito L. <tit...@gm...>]

There is not a problem with the "incudine's osc implementation"
but with "getaddrinfo+bind on OSX", or on your specific system.

Incudine uses getaddrinfo() since 2015. I get a report from
Daniel and Orm after nine years. I can add a little workaround
if getaddrinfo() doesn't work on OSX (really? why?).

Il giorno gio 20 giu 2024 alle ore 14:26 Orm Finnendahl <
orm...@se...> ha scritto:

> Hi,
>
>  unfortunately I couldn't pinpoint the reason, incudine's osc
> implementation doesn't work on OSX for input. I unsuccessfully tried
> various ways to get bind working and I'm still not absolutely sure
> this hasn't got to do with some sort of sandboxing on OSX's side. I
> seemingly can't use debugging tools on the machine without getting an
> Apple ID, which I don't want to do. But I found out that the OSC
> package by Nik Gaffney (https://github.com/zzkt/osc) works on OSX. It
> uses usocket, which uses sb-bsd-sockets. That could be a place to
> start looking, but unfortunately it's a bit over my head to find out
> what the code exactly does and why it works.
>
> I can build a thin compatibility layer to make my own code work on OSX
> and can share it to anybody interested. AFAICT the OSC implementation
> of Nik Gaffney's package doesn't support time tags. Nevertheless for
> me this seems the best way to go at the moment although I reckon that
> this is far from ideal.
>
> --
> Orm
>
>
> Am Donnerstag, den 13. Juni 2024 um 09:58:08 Uhr (+0200) schrieb Orm
> Finnendahl:
> > Am Donnerstag, den 13. Juni 2024 um 09:18:24 Uhr (+0200) schrieb Tito
> Latini:
> > > You get the message "Destination address required" from bind().
> > > If OSC::*ADDRINFO-HINTS-FLAGS* is 0 (default), ask to Apple
> > > because getaddrinfo() in Incudine follows the settings in
> > >
> > >
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getaddrinfo.3.html
> > >
> > > See incudine/src/network/osc.c::32 (I presume AF_UNSPEC is
> > > PF_UNSPEC on osx too) and BIND-STREAM-SOCKET in
> > > incudine/src/network/osc.lisp::417.
> >
> >  :-(
> >
> > incudine.osc::*addrinfo-hints-flags* returns 0 on the Mac as you say.
> >
> > I'll try to investigate further as usocket works for input on the Mac
> > and as far as I know unix sockets, usocket also has to issue a bind()
> > someplace to accomplish that. Thanks for the info, I'll report back...
> >
> > --
> > Orm
> >
> >
> > _______________________________________________
> > incudine-devel mailing list
> > inc...@li...
> > https://lists.sourceforge.net/lists/listinfo/incudine-devel
>
>
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel
>

Re: [incudine-devel] can't open osc input on OSX

[Orm F. <orm...@se...>]

Hi,

 unfortunately I couldn't pinpoint the reason, incudine's osc
implementation doesn't work on OSX for input. I unsuccessfully tried
various ways to get bind working and I'm still not absolutely sure
this hasn't got to do with some sort of sandboxing on OSX's side. I
seemingly can't use debugging tools on the machine without getting an
Apple ID, which I don't want to do. But I found out that the OSC
package by Nik Gaffney (https://github.com/zzkt/osc) works on OSX. It
uses usocket, which uses sb-bsd-sockets. That could be a place to
start looking, but unfortunately it's a bit over my head to find out
what the code exactly does and why it works.

I can build a thin compatibility layer to make my own code work on OSX
and can share it to anybody interested. AFAICT the OSC implementation
of Nik Gaffney's package doesn't support time tags. Nevertheless for
me this seems the best way to go at the moment although I reckon that
this is far from ideal.

--
Orm


Am Donnerstag, den 13. Juni 2024 um 09:58:08 Uhr (+0200) schrieb Orm Finnendahl:
> Am Donnerstag, den 13. Juni 2024 um 09:18:24 Uhr (+0200) schrieb Tito Latini:
> > You get the message "Destination address required" from bind().
> > If OSC::*ADDRINFO-HINTS-FLAGS* is 0 (default), ask to Apple
> > because getaddrinfo() in Incudine follows the settings in
> > 
> > https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getaddrinfo.3.html
> > 
> > See incudine/src/network/osc.c::32 (I presume AF_UNSPEC is
> > PF_UNSPEC on osx too) and BIND-STREAM-SOCKET in
> > incudine/src/network/osc.lisp::417.
> 
>  :-(
> 
> incudine.osc::*addrinfo-hints-flags* returns 0 on the Mac as you say.
> 
> I'll try to investigate further as usocket works for input on the Mac
> and as far as I know unix sockets, usocket also has to issue a bind()
> someplace to accomplish that. Thanks for the info, I'll report back...
> 
> --
> Orm
> 
> 
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel

Re: [incudine-devel] can't open osc input on OSX

[Orm F. <orm...@se...>]

Am Donnerstag, den 13. Juni 2024 um 09:18:24 Uhr (+0200) schrieb Tito Latini:
> You get the message "Destination address required" from bind().
> If OSC::*ADDRINFO-HINTS-FLAGS* is 0 (default), ask to Apple
> because getaddrinfo() in Incudine follows the settings in
> 
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getaddrinfo.3.html
> 
> See incudine/src/network/osc.c::32 (I presume AF_UNSPEC is
> PF_UNSPEC on osx too) and BIND-STREAM-SOCKET in
> incudine/src/network/osc.lisp::417.

 :-(

incudine.osc::*addrinfo-hints-flags* returns 0 on the Mac as you say.

I'll try to investigate further as usocket works for input on the Mac
and as far as I know unix sockets, usocket also has to issue a bind()
someplace to accomplish that. Thanks for the info, I'll report back...

--
Orm

Re: [incudine-devel] can't open osc input on OSX

[Tito L. <tit...@gm...>]

> it's still the same [...]

You get the message "Destination address required" from bind().
If OSC::*ADDRINFO-HINTS-FLAGS* is 0 (default), ask to Apple
because getaddrinfo() in Incudine follows the settings in

https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/getaddrinfo.3.html

See incudine/src/network/osc.c::32 (I presume AF_UNSPEC is
PF_UNSPEC on osx too) and BIND-STREAM-SOCKET in
incudine/src/network/osc.lisp::417.

Re: [incudine-devel] can't open osc input on OSX

[Tito L. <tit...@gm...>]

Please try again with the new change. Thanks for the feedback.

Re: [incudine-devel] can't open osc input on OSX

[Orm F. <orm...@se...>]

Am Dienstag, den 11. Juni 2024 um 17:47:34 Uhr (+0200) schrieb Tito Latini:
> Please try the recent change and let me know if it works.

unfortunately not:

SCRATCH> (incudine.osc:open :port 32145)

OSC:OPEN Failed to assign the address. (Destination address required)
   [Condition of type INCUDINE-NETWORK-ERROR]

0: (INCUDINE.OSC:OPEN :HOST "localhost" :PORT 32145 :DIRECTION :INPUT :PROTOCOL :UDP :BUFFER-SIZE NIL :LATENCY 0 :AUTO-CONNECT-P T :MAX-VALUES NIL :MESSAGE-ENCODING NIL :INPUT-STREAM-CONSTRUCTOR NIL :OUT..
      Locals:
        #:.DEFAULTING-TEMP. = "localhost"
        #:.DEFAULTING-TEMP.#1 = 32145
        #:.DEFAULTING-TEMP.#2 = :INPUT
        #:.DEFAULTING-TEMP.#3 = :UDP
        #:.DEFAULTING-TEMP.#4 = NIL
        #:.DEFAULTING-TEMP.#5 = 0
        #:.DEFAULTING-TEMP.#6 = NIL
        #:.DEFAULTING-TEMP.#7 = NIL
        #:.DEFAULTING-TEMP.#8 = NIL
        #:.DEFAULTING-TEMP.#9 = NIL
        ADDRESS = #.(SB-SYS:INT-SAP #X600000FD0020)
        AUTO-CONNECT-P = T
        AUX-PTR = #.(SB-SYS:INT-SAP #X00000000)
        BUF-PTR = #.(SB-SYS:INT-SAP #X148038000)
        DIRECTION = :INPUT
        FDS-PTR = #.(SB-SYS:INT-SAP #X14805C9FC)
        #:N-SUPPLIED-0 = 0
        #:N-SUPPLIED-1 = 0
        #:N-SUPPLIED-2 = 0
        #:N-SUPPLIED-3 = 0
        OBJ = #<OSC:INPUT-STREAM :UDP "localhost" 32145>
        PROTOCOL = :UDP
        TYPE-VEC-PTR = #.(SB-SYS:INT-SAP #X111604350)
        VALUE-VEC-PTR = #.(SB-SYS:INT-SAP #X13200CC00)

Re: [incudine-devel] can't open osc input on OSX

[Tito L. <tit...@gm...>]

Please try the recent change and let me know if it works.

Re: [incudine-devel] can't open osc input on OSX

[Orm F. <orm...@se...>]

Am Dienstag, den 11. Juni 2024 um 09:22:21 Uhr (+0200) schrieb Tito Latini:
> What is the output of
> 
> (osc:with-stream (s :direction :output) (describe s))
> 
> ?

SCRATCH> (incudine.osc:with-stream (s :direction :output) (describe s))

#<OSC:OUTPUT-STREAM :UDP "localhost" 32126>
  [structure-object]

Slots with :INSTANCE allocation:
  HOST                           = "localhost"
  PORT                           = 32126
  ADDRESS-PTR                    = #.(SB-SYS:INT-SAP #X600000C28020)
  ADDRINFO-PTR                   = #.(SB-SYS:INT-SAP #X600000228060)
  FDS-PTR                        = #.(SB-SYS:INT-SAP #X1382A49FC)
  PROTOCOL                       = :UDP
  SOCKET-FD                      = 14
  DIRECTION                      = :OUTPUT
  BUFFER-POINTER                 = #.(SB-SYS:INT-SAP #X138280000)
  BUFFER-SIZE                    = 149980
  MAX-VALUES                     = 500
  BUFFER-TO-INDEX-P              = NIL
  SINGLE-MESSAGE-P               = T
  MESSAGE-POINTER                = #.(SB-SYS:INT-SAP #X138280014)
  MESSAGE-OFFSET                 = 0
  MESSAGE-LENGTH                 = 0
  MESSAGE-LENGTH-POINTER         = #.(SB-SYS:INT-SAP #X138280010)
  BUNDLE-POINTER                 = #.(SB-SYS:INT-SAP #X138280000)
  BUNDLE-LENGTH                  = 0
  MESSAGE-ENCODING               = NIL
  VALUE-VEC-PTR                  = #.(SB-SYS:INT-SAP #X136018A00)
  TYPE-VEC-PTR                   = #.(SB-SYS:INT-SAP #X135E04B40)
  AUX-BUFFER-POINTER             = #.(SB-SYS:INT-SAP #X00000000)
  TMP-PTR                        = #.(SB-SYS:INT-SAP #X1382A49F4)
  LATENCY                        = 0.0d0

BTW: If you need more: Unfortunately I have to leave the Mac in ca. 40
Minutes, but can do more tests until then or late in the evening.

--
Orm

Re: [incudine-devel] can't open osc input on OSX

[Tito L. <tit...@gm...>]

What is the output of

(osc:with-stream (s :direction :output) (describe s))

?

[incudine-devel] can't open osc input on OSX

[Orm F. <orm...@se...>]

Hi,

 BTW: I can provide access to the OSX machine in case that is
needed. In that case let me know which access you prefer.

Best,
Orm

------------------------------------------------------
Linux:
------------------------------------------------------

CL-USER> (ql:quickload :incudine)
To load "incudine":
  Load 1 ASDF system:
    incudine
; Loading "incudine"
.....
(:INCUDINE)
CL-USER> (in-package :scratch)
#<PACKAGE "INCUDINE.SCRATCH">
SCRATCH> (defparameter *oscin* (incudine.osc:open :port 32145))
*OSCIN*
SCRATCH> 

------------------------------------------------------
OSX:
------------------------------------------------------

CL-USER> (ql:quickload :incudine)
To load "incudine":
  Load 1 ASDF system:
    incudine
; Loading "incudine"
.....
(:INCUDINE)
CL-USER> (in-package :scratch)
#<PACKAGE "INCUDINE.SCRATCH">
SCRATCH> (defparameter *oscin* (incudine.osc:open :port 32145))

OSC:OPEN Failed to assign the address. (Destination address required)
   [Condition of type INCUDINE-NETWORK-ERROR]

Backtrace:
 0: (INCUDINE.OSC:OPEN :HOST "localhost" :PORT 32126 :DIRECTION :INPUT :PROTOCOL :UDP :BUFFER-SIZE NIL :LATENCY 0 :AUTO-CONNECT-P T :MAX-VALUES NIL :MESSAGE-ENCODING NIL :INPUT-STREAM-CONSTRUCTOR NIL :OUT..
      Locals:
        #:.DEFAULTING-TEMP. = "localhost"
        #:.DEFAULTING-TEMP.#1 = 32145
        #:.DEFAULTING-TEMP.#2 = :INPUT
        #:.DEFAULTING-TEMP.#3 = :UDP
        #:.DEFAULTING-TEMP.#4 = NIL
        #:.DEFAULTING-TEMP.#5 = 0
        #:.DEFAULTING-TEMP.#6 = NIL
        #:.DEFAULTING-TEMP.#7 = NIL
        #:.DEFAULTING-TEMP.#8 = NIL
        #:.DEFAULTING-TEMP.#9 = NIL
        ADDRESS = #.(SB-SYS:INT-SAP #X600000C34020)
        AUTO-CONNECT-P = T
        AUX-PTR = #.(SB-SYS:INT-SAP #X00000000)
        BUF-PTR = #.(SB-SYS:INT-SAP #X148038000)
        DIRECTION = :INPUT
        FDS-PTR = #.(SB-SYS:INT-SAP #X14805C9FC)
        #:N-SUPPLIED-0 = 0
        #:N-SUPPLIED-1 = 0
        #:N-SUPPLIED-2 = 0
        #:N-SUPPLIED-3 = 0
        OBJ = #<OSC:INPUT-STREAM :UDP "localhost" 32145>
        PROTOCOL = :UDP
        TYPE-VEC-PTR = #.(SB-SYS:INT-SAP #X135E04B40)
        VALUE-VEC-PTR = #.(SB-SYS:INT-SAP #X136018A00)

...

[incudine-devel] can't open osc input on OSX

[Orm F. <orm...@se...>]

Hi,

 the code below works on Linux, but not on OSX. Trying to do TCP/IP
communication using usocket works on OSX in both directions and OSC
output using incudine also works. It's just the input which doesn't
work as expected.

Any ideas what could be the reason?

Best,
Orm
----------------------------------------------------------------------
Prof. Orm Finnendahl
Komposition
Hochschule für Musik und Darstellende Kunst
Eschersheimer Landstr. 29-39
60322 Frankfurt am Main

------------------------------------------------------
Linux:
------------------------------------------------------

CL-USER> (ql:quickload :incudine)
To load "incudine":
  Load 1 ASDF system:
    incudine
; Loading "incudine"
.....
(:INCUDINE)
CL-USER> (in-package :scratch)
#<PACKAGE "INCUDINE.SCRATCH">
SCRATCH> (defparameter *oscin* (incudine.osc:open :port 32145))
*OSCIN*
SCRATCH> 

------------------------------------------------------
OSX:
------------------------------------------------------

CL-USER> (ql:quickload :incudine)
To load "incudine":
  Load 1 ASDF system:
    incudine
; Loading "incudine"
.....
(:INCUDINE)
CL-USER> (in-package :scratch)
#<PACKAGE "INCUDINE.SCRATCH">
SCRATCH> (defparameter *oscin* (incudine.osc:open :port 32145))

OSC:OPEN Failed to assign the address. (Destination address required)
   [Condition of type INCUDINE-NETWORK-ERROR]

Backtrace:
 0: (INCUDINE.OSC:OPEN :HOST "localhost" :PORT 32126 :DIRECTION :INPUT :PROTOCOL :UDP :BUFFER-SIZE NIL :LATENCY 0 :AUTO-CONNECT-P T :MAX-VALUES NIL :MESSAGE-ENCODING NIL :INPUT-STREAM-CONSTRUCTOR NIL :OUT..
      Locals:
        #:.DEFAULTING-TEMP. = "localhost"
        #:.DEFAULTING-TEMP.#1 = 32145
        #:.DEFAULTING-TEMP.#2 = :INPUT
        #:.DEFAULTING-TEMP.#3 = :UDP
        #:.DEFAULTING-TEMP.#4 = NIL
        #:.DEFAULTING-TEMP.#5 = 0
        #:.DEFAULTING-TEMP.#6 = NIL
        #:.DEFAULTING-TEMP.#7 = NIL
        #:.DEFAULTING-TEMP.#8 = NIL
        #:.DEFAULTING-TEMP.#9 = NIL
        ADDRESS = #.(SB-SYS:INT-SAP #X600000C34020)
        AUTO-CONNECT-P = T
        AUX-PTR = #.(SB-SYS:INT-SAP #X00000000)
        BUF-PTR = #.(SB-SYS:INT-SAP #X148038000)
        DIRECTION = :INPUT
        FDS-PTR = #.(SB-SYS:INT-SAP #X14805C9FC)
        #:N-SUPPLIED-0 = 0
        #:N-SUPPLIED-1 = 0
        #:N-SUPPLIED-2 = 0
        #:N-SUPPLIED-3 = 0
        OBJ = #<OSC:INPUT-STREAM :UDP "localhost" 32145>
        PROTOCOL = :UDP
        TYPE-VEC-PTR = #.(SB-SYS:INT-SAP #X135E04B40)
        VALUE-VEC-PTR = #.(SB-SYS:INT-SAP #X136018A00)

...

[incudine-devel] Profiling DSP functions

[Tito L. <tit...@gm...>]

The new utilities provided by incudine.util package extend
sb-profile:

https://incudine.sourceforge.net/incudine.html#Profiling

profile &rest names

  Extend SB-PROFILE:PROFILE by wrapping profiling code
  around the init-time and performance-time functions of
  the named DSPs.

profile-node node max-number-of-calls

  Wrap profiling code around the functions of a live NODE,
  then call PROFILE-REPORT and remove profiling code after
  MAX-NUMBER-OF-CALLS to the wrapped functions, or when
  the target node is freed.

  If the target node was paused, it is internally unpaused
  for MAX-NUMBER-OF-CALLS to the profiled performance-time
  function.

  If the target node is a group node, the paused nodes of
  that group are not internally unpaused.

  Note: the argument name MAX-NUMBER-OF-CALLS instead of
  MAX-SAMPLES in this context avoids confusion between
  audio samples and program execution samples.

unprofile &rest names

  Extend SB-PROFILE:UNPROFILE by unwrapping any profiling
  code around the functions of the named DSPs.

profile-report &key limit print-no-call-list

  SB-PROFILE:REPORT with a different name.

profile-reset

 Unwrap any profiling code around unreferenced DSP
 functions and call SB-PROFILE:RESET.

Re: [incudine-devel] *logger-stream* on saved image

[Tito L. <tit...@gm...>]

Generally it works from a terminal. If this line in .sbclrc
is not enough:

#+incudine
(setf incudine.util:*logger-stream* *error-output*)

I think you should set an after-hook for your connection.

Il giorno dom 24 mar 2024 alle ore 17:43 Orm Finnendahl <
orm...@se...> ha scritto:

> Hi,
>
>  incudine.util:*logger-stream* seems to get reset when saving/loading
> from a lisp image, breaking incudine.util:msg printout in the repl. It
> can be fixed by setting *logger-stream* to *error-output* after
> loading the image (see below). I'm not sure this is the recommended
> way to fix it though.
>
> --
> Orm
>
> --------------------------------------------------------------------------
> Using the standard sbcl image:
>
> CL-USER> (ql:quickload :incudine)
> To load "incudine":
>   Load 1 ASDF system:
>     incudine
> ; Loading "incudine"
> ....
> (:INCUDINE)
> CL-USER> (incudine.util:msg :warn "test")
> WARN: test
> NIL
> CL-USER> incudine.util:*logger-stream*
> #<SB-SYS:FD-STREAM for "socket 127.0.0.1:46813, peer: 127.0.0.1:38998"
> {1001480183}>
> CL-USER> sb-sys:*stderr*
> #<SB-SYS:FD-STREAM for "standard error" {1001460853}>
> CL-USER>
>
> --------------------------------------------------------------------------
> Using a custom image:
>
> cl-user> (incudine.util:msg :warn "test")
> nil
> cl-user> incudine.util:*logger-stream*
> #<synonym-stream :SYMBOL sb-sys:*stderr* {1000009C03}>
>
> --------------------------------------------------------------------------
> Setting *logger-stream* to *standard-error* after loading seems to fix
> it here:
>
> cl-user> (setf incudine.util:*logger-stream* *error-output*)
> #<sb-sys:fd-stream for "socket 127.0.0.1:46641, peer: 127.0.0.1:41278"
> {100EC00053}>
> cl-user> (incudine.util:msg :warn "test")
> warn: test
> nil
> cl-user>
>
>
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel
>

[incudine-devel] *logger-stream* on saved image

[Orm F. <orm...@se...>]

Hi,

 incudine.util:*logger-stream* seems to get reset when saving/loading
from a lisp image, breaking incudine.util:msg printout in the repl. It
can be fixed by setting *logger-stream* to *error-output* after
loading the image (see below). I'm not sure this is the recommended
way to fix it though.

--
Orm

--------------------------------------------------------------------------
Using the standard sbcl image:

CL-USER> (ql:quickload :incudine)
To load "incudine":
  Load 1 ASDF system:
    incudine
; Loading "incudine"
....
(:INCUDINE)
CL-USER> (incudine.util:msg :warn "test")
WARN: test
NIL
CL-USER> incudine.util:*logger-stream*
#<SB-SYS:FD-STREAM for "socket 127.0.0.1:46813, peer: 127.0.0.1:38998" {1001480183}>
CL-USER> sb-sys:*stderr*
#<SB-SYS:FD-STREAM for "standard error" {1001460853}>
CL-USER>

--------------------------------------------------------------------------
Using a custom image:

cl-user> (incudine.util:msg :warn "test")
nil
cl-user> incudine.util:*logger-stream*
#<synonym-stream :SYMBOL sb-sys:*stderr* {1000009C03}>

--------------------------------------------------------------------------
Setting *logger-stream* to *standard-error* after loading seems to fix
it here:

cl-user> (setf incudine.util:*logger-stream* *error-output*)
#<sb-sys:fd-stream for "socket 127.0.0.1:46641, peer: 127.0.0.1:41278" {100EC00053}>
cl-user> (incudine.util:msg :warn "test")
warn: test
nil
cl-user> 

Re: [incudine-devel] ensure buffer is loaded

[Orm F. <orm...@se...>]

Hi,

 it's solved: The problem was that the code scheduled playback in the
rt-thread from the nrt thread (with the current time) directly before
executing the buffer load in the nrt thread which obviously caused a
segfault as the buffer was created but not yet filled when the
rt-thread tried to access it. Sorry for the noise...

--
Orm

Am Donnerstag, den 21. März 2024 um 14:12:06 Uhr (+0100) schrieb Orm Finnendahl:
> Hi,
> 
>  is there a recommended way or builtin mechanism in incudine to read
> buffers into memory synchronously to ensure they are loaded before
> code after loading them is executed, or is there any way to verify the
> buffer data is available?
> 
> --
> Orm
> 
> 
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel

[incudine-devel] ensure buffer is loaded

[Orm F. <orm...@se...>]

Hi,

 is there a recommended way or builtin mechanism in incudine to read
buffers into memory synchronously to ensure they are loaded before
code after loading them is executed, or is there any way to verify the
buffer data is available?

--
Orm

Re: [incudine-devel] pipewire-jack-audio and incudine

[Orm F. <orm...@se...>]

Hi all,

 FYI: I answered Daniel privately with explanations how to get it
working as I don't think this is incudine related..

--
Orm


Am Dienstag, den 19. März 2024 um 20:52:36 Uhr (+0100) schrieb Daniel Hensel via incudine-devel:
> Hi,
> 
> I am trying to run incudine on Asahi Linux. It is not possible to use pulse audio and jack like on other systems, so they use pipewire-jack. The wrote 
> 
> Is there a chance to configure incudine, so I can use pipewire-jack? Right now it cannot set realtime priority. When compiling cm-incudine, it complains about missing jackmidi packages.
> 
> 
> The developers of Asahi wrote:
> 
> > The only supported sound server for the internal speakers is PipeWire, as we rely on it to implement automatically configured speaker DSP processing. Attempting to use anything else will break things and give you really poor sound without a lot of manual work and configuration. There’s a complex DSP chain including a software crossover, compressor, bass boost and EQ driving the 6 independent speakers in your 16" MacBook, you’d have to re-create all that on your own in JACK or PulseAudio if you tried to use those!
> > 
> > If you want to use JACK client apps, then uninstall JACK and install pipewire-jack-audio-connection-kit instead. That will allow JACK-based apps to use PipeWire as an audio server. It works really well, even with complex things like Ardour. QJackctl also works (you don’t need to “start” anything, don’t let it try to do that; once the package is installed JACK will appear to already be started when PipeWire is running, and you can still use qjackctl to manage ports and patchbays). This is basically the future-proof solution: PipeWire is endorsed by the developers of PulseAudio and JACK as the next generation and replacement.
> > 
> > If you want to use JACK with a different sound card (e.g. an external audio interface) you can do so in parallel with PipeWire driving the internal speakers. You need to make sure they don’t conflict with each other by disabling the external card in PipeWire (e.g. via pavucontrol) and pointing JACK at it in qjackctl. You could also just run JACK with the dummy backend if you only need it for internal audio routing reasons (e.g. some synth writing to a file) and don’t actually need to play back audio through hardware.
> > 
> > Finally, it’s probably possible to plug JACK into PipeWire as a client and route through it, though honestly I don’t know why you’d want to do that when the integrated JACK compatibility in PipeWire works as well as it does these days.
> 
> I installed the pipewire-jack-audio-connection-kit-devel packages. Any idea?
> 
> 
> 
> All the best, Daniel
> 
> 
> 
> 
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel

Re: [incudine-devel] pipewire-jack-audio and incudine

[Cian <cia...@gm...>]

Have you tried using the PortAudio interface instead?

On Tue, Mar 19, 2024 at 3:53 PM Daniel Hensel via incudine-devel <
inc...@li...> wrote:

> Hi,
>
> I am trying to run incudine on Asahi Linux. It is not possible to use
> pulse audio and jack like on other systems, so they use pipewire-jack. The
> wrote
>
> Is there a chance to configure incudine, so I can use pipewire-jack? Right
> now it cannot set realtime priority. When compiling cm-incudine, it
> complains about missing jackmidi packages.
>
>
> The developers of Asahi wrote:
>
> > The only supported sound server for the internal speakers is PipeWire,
> as we rely on it to implement automatically configured speaker DSP
> processing. Attempting to use anything else will break things and give you
> really poor sound without a lot of manual work and configuration. There’s a
> complex DSP chain including a software crossover, compressor, bass boost
> and EQ driving the 6 independent speakers in your 16" MacBook, you’d have
> to re-create all that on your own in JACK or PulseAudio if you tried to use
> those!
> >
> > If you want to use JACK client apps, then uninstall JACK and install
> pipewire-jack-audio-connection-kit instead. That will allow JACK-based apps
> to use PipeWire as an audio server. It works really well, even with complex
> things like Ardour. QJackctl also works (you don’t need to “start”
> anything, don’t let it try to do that; once the package is installed JACK
> will appear to already be started when PipeWire is running, and you can
> still use qjackctl to manage ports and patchbays). This is basically the
> future-proof solution: PipeWire is endorsed by the developers of PulseAudio
> and JACK as the next generation and replacement.
> >
> > If you want to use JACK with a different sound card (e.g. an external
> audio interface) you can do so in parallel with PipeWire driving the
> internal speakers. You need to make sure they don’t conflict with each
> other by disabling the external card in PipeWire (e.g. via pavucontrol) and
> pointing JACK at it in qjackctl. You could also just run JACK with the
> dummy backend if you only need it for internal audio routing reasons (e.g.
> some synth writing to a file) and don’t actually need to play back audio
> through hardware.
> >
> > Finally, it’s probably possible to plug JACK into PipeWire as a client
> and route through it, though honestly I don’t know why you’d want to do
> that when the integrated JACK compatibility in PipeWire works as well as it
> does these days.
>
> I installed the pipewire-jack-audio-connection-kit-devel packages. Any
> idea?
>
>
>
> All the best, Daniel
>
>
>
>
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel
>

[incudine-devel] pipewire-jack-audio and incudine

[Daniel H. <dan...@ic...>]

Hi,

I am trying to run incudine on Asahi Linux. It is not possible to use pulse audio and jack like on other systems, so they use pipewire-jack. The wrote 

Is there a chance to configure incudine, so I can use pipewire-jack? Right now it cannot set realtime priority. When compiling cm-incudine, it complains about missing jackmidi packages.


The developers of Asahi wrote:

> The only supported sound server for the internal speakers is PipeWire, as we rely on it to implement automatically configured speaker DSP processing. Attempting to use anything else will break things and give you really poor sound without a lot of manual work and configuration. There’s a complex DSP chain including a software crossover, compressor, bass boost and EQ driving the 6 independent speakers in your 16" MacBook, you’d have to re-create all that on your own in JACK or PulseAudio if you tried to use those!
> 
> If you want to use JACK client apps, then uninstall JACK and install pipewire-jack-audio-connection-kit instead. That will allow JACK-based apps to use PipeWire as an audio server. It works really well, even with complex things like Ardour. QJackctl also works (you don’t need to “start” anything, don’t let it try to do that; once the package is installed JACK will appear to already be started when PipeWire is running, and you can still use qjackctl to manage ports and patchbays). This is basically the future-proof solution: PipeWire is endorsed by the developers of PulseAudio and JACK as the next generation and replacement.
> 
> If you want to use JACK with a different sound card (e.g. an external audio interface) you can do so in parallel with PipeWire driving the internal speakers. You need to make sure they don’t conflict with each other by disabling the external card in PipeWire (e.g. via pavucontrol) and pointing JACK at it in qjackctl. You could also just run JACK with the dummy backend if you only need it for internal audio routing reasons (e.g. some synth writing to a file) and don’t actually need to play back audio through hardware.
> 
> Finally, it’s probably possible to plug JACK into PipeWire as a client and route through it, though honestly I don’t know why you’d want to do that when the integrated JACK compatibility in PipeWire works as well as it does these days.

I installed the pipewire-jack-audio-connection-kit-devel packages. Any idea?



All the best, Daniel

Re: [incudine-devel] Strange behaviour

[Orm F. <orm...@se...>]

Hi Tito,

 thanks! (especially for mentioning without-follow and dsp-debug).

--
Orm

Am Dienstag, den 19. März 2024 um 15:06:05 Uhr (+0100) schrieb Tito Latini:
> I prefer a simple anaphoric ~ with an optional independent
> initial value, but you can do whatever you like. If that problem
> will become a faq, I'll add some details to the docstring.
> 
> Your example works if the initial value doesn't depend on a
> variable value:
> 
> (dsp! ipole*-test (freq coef)
>   (with-samples ((f0 (without-follow (freq) freq)))
>     (out (ipole* freq coef f0))))
> 
> (with-buffer (b 20)
>   (buffer->list
>     (bounce-to-buffer (b)
>       (ipole*-test 123 .5 :id 7)
>       (at 5 #'set-control 7 :freq 456))))
> ;; (123.0d0 123.0d0 123.0d0 123.0d0 123.0d0 289.5d0 372.75d0
> ;;  414.375d0 435.1875d0 445.59375d0 450.796875d0 453.3984375d0
> ;;  454.69921875d0 455.349609375d0 455.6748046875d0
> ;;  455.83740234375d0 455.918701171875d0 455.9593505859375d0
> ;;  455.97967529296875d0 455.9898376464844d0)
> 
> This closure is a kind of
> 
>     (let (init-time-bindings)
>       (initialize-block)
>       (lambda () ...))
> 
> It works...
> 
> (dsp! lag-test (freq time)
>   (with-samples ((f0 (without-follow (freq) freq)))
>     (out (+ f0 (lag (- freq f0) time)))))
> 
> (with-buffer (b 50)
>   (buffer->list
>     (bounce-to-buffer (b)
>       (lag-test 123 8e-4 :id 7)
>       (at 5 #'set-control 7 :freq 456))))
> ;; (123.0d0 123.0d0 123.0d0 123.0d0 123.0d0 177.82427186304386d0
> ;;  223.6224152416645d0 261.8804689403687d0 293.83981411976754d0
> ;;  320.5374541079345d0 342.83966264621273d0 361.4700923735334d0
> ;;  377.03325560146686d0 390.0341392742737d0 400.894590571892d0
> ;;  409.9670048289819d0 417.54575990984097d0 423.876768056957d0
> ;;  429.1654551475426d0 433.58342626559715d0 437.2740338711613d0
> ;;  440.3570292403673d0 442.9324481042464d0 445.0838565658597d0
> ;;  446.8810626178996d0 448.3823812429397d0 449.6365265933484d0
> ;;  450.6841926475211d0 451.55937363089606d0 452.29046704621726d0
> ;;  452.901195103704d0 453.4113744493048d0 453.8375591668511d0
> 454.1935779179751d0
> ;;  454.4909826486788d0 454.7394234219968d0 454.94696153916385d0
> ;;  455.12033110931134d0 455.26515755499474d0 455.38614014352765d0
> ;;  455.4872044668221d0 455.5716298173359d0 455.6421555931689d0
> ;;  455.70107018489495d0 455.75028522829217d0 455.7913976322931d0
> ;;  455.82574139481096d0 455.85443088773997d0 455.87839701562405d0
> ;;  455.898417421254d0)
> 
> ...but the following example doesn't work because `(- freq f0)'
> occurs before the INITIALIZE block.
> DSP-DEBUG (or [C-c i d] from Emacs) helps to understand the order:
> 
> (funcall
>  (dsp-debug lag-test-2 (freq time)
>    (:defaults 123 .001)
>    (with-samples (f0)
>      (initialize (setf f0 freq))
>      (out (+ f0 (lag (- freq f0) time))))))
> [...]
> (SETF #:FREQ1832 123.0d0)
> (SETF #:TIME1833 0.001d0)
> (SETF #:IN1835 (- #:FREQ1832 #:F01834))      ; from init-time-binding
> [...]
> (PROGN (SETF #:F01834 #:FREQ1832))           ; from initialize-block
> [...]
> 
> Il giorno lun 18 mar 2024 alle ore 11:25 Orm Finnendahl <
> orm...@se...> ha scritto:
> 
> > Hi,
> >
> >  I could boil down the problem by redefining ~ and ilag using the dsps
> > ilag-test1 and ilag-test2 like below.
> >
> > Judging from the output of *test* in the second try with ilag-test2,
> > it seems strange to me that the initial assignment to 'it in the ~
> > vug-macro seems not to be made, although the correct value of
> > 'initial-value is present. I obviously don't fully understand the
> > sequence of initialization in dsps, vug-macros and vugs.
> >
> > --
> > Orm
> > ------------------------------------------------------------
> > ----------------
> > (require 'incudine)
> > (in-package :scratch)
> >
> > (defvar *test* nil)
> >
> > (define-vug-macro incudine.vug:~ (in &key (type 'sample) (initial-value 0))
> >   "Anaphoric VUG MACRO for recursive composition."
> >   (let ((it (alexandria:ensure-symbol 'it)))
> >     `(with ((,it ,(incudine.vug::coerce-number initial-value type)))
> >        (declare (type ,type ,it))
> >        (reduce-warnings (push (list ,it ,in ,initial-value) *test*))
> >        (setf ,it ,in))))
> >
> > (define-vug ilag (in time init)
> >   "Scaled one pole filter with the coefficient calculated from
> > a 60 dB lag TIME and initial-value init."
> >   (with-samples ((coef (t60->pole time))
> >                  (g (- 1 (abs coef))))
> >     (~ (+ (* g in) (* coef it)) :initial-value init)))
> >
> > ;;; Testing:
> >
> > (dsp! ilag-test1 (val initial-val)
> >   (ilag val 0.5 initial-val))
> >
> > (dsp! ilag-test2 (val initial-val)
> >   (with-samples (start-freq)
> >     (initialize
> >      (setf start-freq initial-val))
> >     (ilag val 0.5 start-freq)))
> >
> > (progn
> >   (setf *test* nil)
> >   (ilag-test1 600 600 :id 1)
> >   (at (+ (now) 10) (lambda () (free 1))))
> >
> > (reverse *test*)
> >
> > -> ((600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0
> > 600.0d0)
> >  (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0
> > 600.0d0)
> >  (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0
> > 600.0d0)
> >  (600.0d0 600.0d0 600.0d0))
> >
> > (progn
> >   (setf *test* nil)
> >   (ilag-test2 600 600 :id 1)
> >   (at (+ (now) 10) (lambda () (free 1))))
> >
> > (reverse *test*)
> >
> > -> ((0.0d0 0.17266903171135883d0 600.0d0)
> >  (0.17266903171135883d0 0.3452883724318641d0 600.0d0)
> >  (0.3452883724318641d0 0.5178580364616746d0 600.0d0)
> >  (0.5178580364616746d0 0.6903780380968338d0 600.0d0)
> >  (0.6903780380968338d0 0.8628483916292711d0 600.0d0)
> >  (0.8628483916292711d0 1.0352691113468027d0 600.0d0)
> >  (1.0352691113468027d0 1.2076402115331333d0 600.0d0)
> >  (1.2076402115331333d0 1.3799617064678569d0 600.0d0)
> >  (1.3799617064678569d0 1.552233610426458d0 600.0d0)
> >  (1.552233610426458d0 1.7244559376803132d0 600.0d0))
> >
> >
> > _______________________________________________
> > incudine-devel mailing list
> > inc...@li...
> > https://lists.sourceforge.net/lists/listinfo/incudine-devel
> >

Re: [incudine-devel] Strange behaviour

[Tito L. <tit...@gm...>]

I prefer a simple anaphoric ~ with an optional independent
initial value, but you can do whatever you like. If that problem
will become a faq, I'll add some details to the docstring.

Your example works if the initial value doesn't depend on a
variable value:

(dsp! ipole*-test (freq coef)
  (with-samples ((f0 (without-follow (freq) freq)))
    (out (ipole* freq coef f0))))

(with-buffer (b 20)
  (buffer->list
    (bounce-to-buffer (b)
      (ipole*-test 123 .5 :id 7)
      (at 5 #'set-control 7 :freq 456))))
;; (123.0d0 123.0d0 123.0d0 123.0d0 123.0d0 289.5d0 372.75d0
;;  414.375d0 435.1875d0 445.59375d0 450.796875d0 453.3984375d0
;;  454.69921875d0 455.349609375d0 455.6748046875d0
;;  455.83740234375d0 455.918701171875d0 455.9593505859375d0
;;  455.97967529296875d0 455.9898376464844d0)

This closure is a kind of

    (let (init-time-bindings)
      (initialize-block)
      (lambda () ...))

It works...

(dsp! lag-test (freq time)
  (with-samples ((f0 (without-follow (freq) freq)))
    (out (+ f0 (lag (- freq f0) time)))))

(with-buffer (b 50)
  (buffer->list
    (bounce-to-buffer (b)
      (lag-test 123 8e-4 :id 7)
      (at 5 #'set-control 7 :freq 456))))
;; (123.0d0 123.0d0 123.0d0 123.0d0 123.0d0 177.82427186304386d0
;;  223.6224152416645d0 261.8804689403687d0 293.83981411976754d0
;;  320.5374541079345d0 342.83966264621273d0 361.4700923735334d0
;;  377.03325560146686d0 390.0341392742737d0 400.894590571892d0
;;  409.9670048289819d0 417.54575990984097d0 423.876768056957d0
;;  429.1654551475426d0 433.58342626559715d0 437.2740338711613d0
;;  440.3570292403673d0 442.9324481042464d0 445.0838565658597d0
;;  446.8810626178996d0 448.3823812429397d0 449.6365265933484d0
;;  450.6841926475211d0 451.55937363089606d0 452.29046704621726d0
;;  452.901195103704d0 453.4113744493048d0 453.8375591668511d0
454.1935779179751d0
;;  454.4909826486788d0 454.7394234219968d0 454.94696153916385d0
;;  455.12033110931134d0 455.26515755499474d0 455.38614014352765d0
;;  455.4872044668221d0 455.5716298173359d0 455.6421555931689d0
;;  455.70107018489495d0 455.75028522829217d0 455.7913976322931d0
;;  455.82574139481096d0 455.85443088773997d0 455.87839701562405d0
;;  455.898417421254d0)

...but the following example doesn't work because `(- freq f0)'
occurs before the INITIALIZE block.
DSP-DEBUG (or [C-c i d] from Emacs) helps to understand the order:

(funcall
 (dsp-debug lag-test-2 (freq time)
   (:defaults 123 .001)
   (with-samples (f0)
     (initialize (setf f0 freq))
     (out (+ f0 (lag (- freq f0) time))))))
[...]
(SETF #:FREQ1832 123.0d0)
(SETF #:TIME1833 0.001d0)
(SETF #:IN1835 (- #:FREQ1832 #:F01834))      ; from init-time-binding
[...]
(PROGN (SETF #:F01834 #:FREQ1832))           ; from initialize-block
[...]

Il giorno lun 18 mar 2024 alle ore 11:25 Orm Finnendahl <
orm...@se...> ha scritto:

> Hi,
>
>  I could boil down the problem by redefining ~ and ilag using the dsps
> ilag-test1 and ilag-test2 like below.
>
> Judging from the output of *test* in the second try with ilag-test2,
> it seems strange to me that the initial assignment to 'it in the ~
> vug-macro seems not to be made, although the correct value of
> 'initial-value is present. I obviously don't fully understand the
> sequence of initialization in dsps, vug-macros and vugs.
>
> --
> Orm
> ------------------------------------------------------------
> ----------------
> (require 'incudine)
> (in-package :scratch)
>
> (defvar *test* nil)
>
> (define-vug-macro incudine.vug:~ (in &key (type 'sample) (initial-value 0))
>   "Anaphoric VUG MACRO for recursive composition."
>   (let ((it (alexandria:ensure-symbol 'it)))
>     `(with ((,it ,(incudine.vug::coerce-number initial-value type)))
>        (declare (type ,type ,it))
>        (reduce-warnings (push (list ,it ,in ,initial-value) *test*))
>        (setf ,it ,in))))
>
> (define-vug ilag (in time init)
>   "Scaled one pole filter with the coefficient calculated from
> a 60 dB lag TIME and initial-value init."
>   (with-samples ((coef (t60->pole time))
>                  (g (- 1 (abs coef))))
>     (~ (+ (* g in) (* coef it)) :initial-value init)))
>
> ;;; Testing:
>
> (dsp! ilag-test1 (val initial-val)
>   (ilag val 0.5 initial-val))
>
> (dsp! ilag-test2 (val initial-val)
>   (with-samples (start-freq)
>     (initialize
>      (setf start-freq initial-val))
>     (ilag val 0.5 start-freq)))
>
> (progn
>   (setf *test* nil)
>   (ilag-test1 600 600 :id 1)
>   (at (+ (now) 10) (lambda () (free 1))))
>
> (reverse *test*)
>
> -> ((600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0
> 600.0d0)
>  (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0
> 600.0d0)
>  (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0
> 600.0d0)
>  (600.0d0 600.0d0 600.0d0))
>
> (progn
>   (setf *test* nil)
>   (ilag-test2 600 600 :id 1)
>   (at (+ (now) 10) (lambda () (free 1))))
>
> (reverse *test*)
>
> -> ((0.0d0 0.17266903171135883d0 600.0d0)
>  (0.17266903171135883d0 0.3452883724318641d0 600.0d0)
>  (0.3452883724318641d0 0.5178580364616746d0 600.0d0)
>  (0.5178580364616746d0 0.6903780380968338d0 600.0d0)
>  (0.6903780380968338d0 0.8628483916292711d0 600.0d0)
>  (0.8628483916292711d0 1.0352691113468027d0 600.0d0)
>  (1.0352691113468027d0 1.2076402115331333d0 600.0d0)
>  (1.2076402115331333d0 1.3799617064678569d0 600.0d0)
>  (1.3799617064678569d0 1.552233610426458d0 600.0d0)
>  (1.552233610426458d0 1.7244559376803132d0 600.0d0))
>
>
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel
>

[incudine-devel] Strange behaviour

[Orm F. <orm...@se...>]

Hi,

 I could boil down the problem by redefining ~ and ilag using the dsps
ilag-test1 and ilag-test2 like below.

Judging from the output of *test* in the second try with ilag-test2,
it seems strange to me that the initial assignment to 'it in the ~
vug-macro seems not to be made, although the correct value of
'initial-value is present. I obviously don't fully understand the
sequence of initialization in dsps, vug-macros and vugs.

--
Orm
----------------------------------------------------------------------------
(require 'incudine)
(in-package :scratch)

(defvar *test* nil)

(define-vug-macro incudine.vug:~ (in &key (type 'sample) (initial-value 0))
  "Anaphoric VUG MACRO for recursive composition."
  (let ((it (alexandria:ensure-symbol 'it)))
    `(with ((,it ,(incudine.vug::coerce-number initial-value type)))
       (declare (type ,type ,it))
       (reduce-warnings (push (list ,it ,in ,initial-value) *test*))
       (setf ,it ,in))))

(define-vug ilag (in time init)
  "Scaled one pole filter with the coefficient calculated from
a 60 dB lag TIME and initial-value init."
  (with-samples ((coef (t60->pole time))
                 (g (- 1 (abs coef))))
    (~ (+ (* g in) (* coef it)) :initial-value init)))

;;; Testing:

(dsp! ilag-test1 (val initial-val)
  (ilag val 0.5 initial-val))

(dsp! ilag-test2 (val initial-val)
  (with-samples (start-freq)
    (initialize
     (setf start-freq initial-val))
    (ilag val 0.5 start-freq)))

(progn
  (setf *test* nil)
  (ilag-test1 600 600 :id 1)
  (at (+ (now) 10) (lambda () (free 1))))

(reverse *test*)

-> ((600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0)
 (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0)
 (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0) (600.0d0 600.0d0 600.0d0)
 (600.0d0 600.0d0 600.0d0))

(progn
  (setf *test* nil)
  (ilag-test2 600 600 :id 1)
  (at (+ (now) 10) (lambda () (free 1))))

(reverse *test*)

-> ((0.0d0 0.17266903171135883d0 600.0d0)
 (0.17266903171135883d0 0.3452883724318641d0 600.0d0)
 (0.3452883724318641d0 0.5178580364616746d0 600.0d0)
 (0.5178580364616746d0 0.6903780380968338d0 600.0d0)
 (0.6903780380968338d0 0.8628483916292711d0 600.0d0)
 (0.8628483916292711d0 1.0352691113468027d0 600.0d0)
 (1.0352691113468027d0 1.2076402115331333d0 600.0d0)
 (1.2076402115331333d0 1.3799617064678569d0 600.0d0)
 (1.3799617064678569d0 1.552233610426458d0 600.0d0)
 (1.552233610426458d0 1.7244559376803132d0 600.0d0))

[incudine-devel] Strange behaviour

[Orm F. <orm...@se...>]

Hi,

 trying to define a sine dsp with a lag on frequency changes, but
initialized to the starting frequency to avoid a glissando from 0 Hz
when starting the dsp, I get surprising results. Below is what I
did. Any help greatly appreciated!

--
Orm


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;                           Definitions
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(in-package :scratch)

(defvar *test* nil)

(define-vug ipole (in coef initial-value)
  "One pole filter with initial value."
  (~ (+ in (* coef it)) :initial-value initial-value))

(define-vug ipole* (in coef initial-value)
  "Scaled one pole filter with initial-value."
  (with-samples ((g (- 1 (abs coef))))
    (ipole (* g in) coef initial-value)))

(define-vug ilag (in time init)
  "Scaled one pole filter with the coefficient calculated from
a 60 dB lag TIME and initial-value init."
  (with-samples (test)
    (setf test (ipole* in (t60->pole time) init))
    (reduce-warnings (push (list test init) *test*))
    test))

(dsp! simple (freq amp)
  (with-samples (start-freq)
    (initialize
     (setf start-freq freq))
    (out (sine (ilag freq 0.5 start-freq) amp))))

(dsp! ilag-test (val initial-val)
  (ilag val 0.5 initial-val))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;                            Testing:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

(rt-start)

;;; This works as expected:

;;; initial value = freq

(progn
  (setf *test* nil)
  (ilag-test 600 600 :id 1)
  (at (+ (now) 10) (lambda () (free 1))))

(reverse *test*)

-> ((600.0d0 600.0d0) (600.0d0 600.0d0) (600.0d0 600.0d0) (600.0d0 600.0d0)
 (600.0d0 600.0d0) (600.0d0 600.0d0) (600.0d0 600.0d0) (600.0d0 600.0d0)
 (600.0d0 600.0d0) (600.0d0 600.0d0))


;;; initial value = 0

(progn
  (setf *test* nil)
  (ilag-test 600 0 :id 1)
  (at (+ (now) 10) (lambda () (free 1))))

(reverse *test*)

-> ((0.18793669039294247d0 0.0d0) (0.3758145137865585d0 0.0d0)
 (0.5636334886196299d0 0.0d0) (0.7513936333251627d0 0.0d0)
 (0.9390949663303895d0 0.0d0) (1.1267375060567706d0 0.0d0)
 (1.3143212709199965d0 0.0d0) (1.5018462793299894d0 0.0d0)
 (1.6893125496909047d0 0.0d0) (1.8767201004011336d0 0.0d0))

;;; The following doesn't work, the ilag still starts at 0, although
;;; its initial-value seems to be correct:

(progn
  (setf *test* nil)
  (simple 600 0.1 :id 1)
  (at (+ (now) 10) (lambda () (free 1))))

(reverse *test*)

-> ((0.18793669039294247d0 600.0d0) (0.3758145137865585d0 600.0d0)
 (0.5636334886196299d0 600.0d0) (0.7513936333251627d0 600.0d0)
 (0.9390949663303895d0 600.0d0) (1.1267375060567706d0 600.0d0)
 (1.3143212709199965d0 600.0d0) (1.5018462793299894d0 600.0d0)
 (1.6893125496909047d0 600.0d0) (1.8767201004011336d0 600.0d0))

Re: [incudine-devel] JACK shutdown (it was another thread)

[Tito L. <tit...@gm...>]

Normal JACK clients set a flag for cleanup when
the JACK server shuts down the client thread.
No more music.

The JACK server doesn't shut down the Incudine
client thread, because jack_cycle_wait() works
better without interrupts (it implies no xruns
etc) but it blocks (also a possible gc) in the
lisp thread. No more music, so Incudine sends a
SIGQUIT.

Thread restart vs process restart, but the end of
music is the same. Personally, I stop the audio
server after the clients, after the work. If JACK
crashes (I don't remember), Incudine SIGQUIT.

If it is a problem, the solution is an alternative
to jack_cycle_wait() called without interrupts from
the lisp thread.

The question is: that's a real problem?

Il giorno mer 13 mar 2024 alle ore 09:50 Orm Finnendahl <
orm...@se...> ha scritto:

> Hi Tito,
>
>  this is slightly unrelated: Is it somehow possible to prevent
> crashing of the lisp process when stopping the jack server without
> prior stopping of the realtime thread in incudine or is that
> inevitable?
>
> Other programs seem to survive this, but that could be due to the
> architecture of their handling of audio.
>
> Best,
> Orm
> ----------------------------------------------------------------------
> Prof. Orm Finnendahl
> Komposition
> Hochschule für Musik und Darstellende Kunst
> Eschersheimer Landstr. 29-39
> 60322 Frankfurt am Main
>
>
> https://www.youtube.com/watch?v=2rWha1HTfFE&list=PLiGfneJSWmNw6dTUvcTHbTkCYOOTiB_N6
>
>
> Am Dienstag, den 12. März 2024 um 18:35:12 Uhr (+0100) schrieb Tito Latini:
> > The new configuration variables
> >
> >     *AUDIO-INPUT-PORT-NAME*
> >     *AUDIO-OUTPUT-PORT-NAME*
> >
> > are set to a control-string, or to a function of one argument
> > (the port number) to get the short name of a JACK port.
> >
> > The default is "in_~D" for the input ports and "out_~D" for
> > the output ports. If the function doesn't return a string,
> > the port name is the default.
> >
> > The setfable AUDIO-PORT-NAME returns the short name of a port.
> >
> > RESET-AUDIO-PORT-NAMES sets the names of the initial configuration.
> >
> > Example:
> >
> > ;; .incudinerc
> > (setq *audio-input-port-name*
> >       (lambda (n)
> >         (if (> n 2)
> >             (format nil "Track/input ~D" (- n 2))
> >             (format nil "Master/input ~D" n))))
> > (setq *audio-output-port-name*
> >       (lambda (n)
> >         (if (> n 2)
> >             (format nil "Track/output ~D" (- n 2))
> >             (format nil "Master/output ~D" n))))
> > ;; end of .incudinerc
> >
> > * (require :incudine)
> > * (in-package :scratch)
> > * (set-number-of-channels 8 8)
> > * (rt-start)
> >
> > shell> jack_lsp |grep incudine
> > incudine:Master/input 1
> > incudine:Master/input 2
> > incudine:Track/input 1
> > incudine:Track/input 2
> > incudine:Track/input 3
> > incudine:Track/input 4
> > incudine:Track/input 5
> > incudine:Track/input 6
> > incudine:Master/output 1
> > incudine:Master/output 2
> > incudine:Track/output 1
> > incudine:Track/output 2
> > incudine:Track/output 3
> > incudine:Track/output 4
> > incudine:Track/output 5
> > incudine:Track/output 6
> >
> > * (dotimes (i 8)
> >     (setf (audio-port-name :input i) (format nil "input ~R" (1+ i)))
> >     (setf (audio-port-name :output i) (format nil "output ~R" (1+ i))))
> >
> > shell> jack_lsp |grep incudine
> > incudine:input one
> > incudine:input two
> > incudine:input three
> > incudine:input four
> > incudine:input five
> > incudine:input six
> > incudine:input seven
> > incudine:input eight
> > incudine:output one
> > incudine:output two
> > incudine:output three
> > incudine:output four
> > incudine:output five
> > incudine:output six
> > incudine:output seven
> > incudine:output eight
> >
> > * (set-number-of-channels 2 2)
> > * (rt-start)
> >
> > shell> jack_lsp |grep incudine
> > incudine:input one
> > incudine:input two
> > incudine:output one
> > incudine:output two
> >
> > * (reset-audio-port-names)
> > * (dotimes (i 2)
> >     (format t "~A~%~A~%"
> >             (audio-port-name :input i)
> >             (audio-port-name :output i)))
> > Master/input 1
> > Master/output 1
> > Master/input 2
> > Master/output 2
>
>
> > _______________________________________________
> > incudine-devel mailing list
> > inc...@li...
> > https://lists.sourceforge.net/lists/listinfo/incudine-devel
>
>
>
> _______________________________________________
> incudine-devel mailing list
> inc...@li...
> https://lists.sourceforge.net/lists/listinfo/incudine-devel
>