would be useful to include some more structured testing and look more closely at protocol coverage (or deviation)

Building with SBCL 2.2.7.28-02bc916fd / ASDF 3.3.5 for quicklisp dist creation.

Trying to build commit id e46e9b1

osc fails to build with the following error:

Unhandled PACKAGE-DOES-NOT-EXIST in thread #<SB-THREAD:THREAD "main thread" RUNNING {10016C8003}>: The name "SB-BSD-SOCKETS" does not designate any package.

Full log here

There are some obvious (and some not so obvious) improvements that could be gleaned from fosc version by @8c6794b6. Quite a few implementation specific optimisations, which could be benchmarked against ieee-floats library (in particular tools/benchmarks.lisp)

Hi,

Since commit 829bf7c on the 24th of august, the library does load anymore in ECL using quicklisp

It seems to be connected to SB libraries

quicklisp/local-projects/osc/devices/socket-functions.lisp" 0x55b0e2262aa0>, position 1958:
;;; Cannot find the external symbol NOT-CONNECTED-ERROR in #<"SB-BSD-SOCKETS" package>

OR

;;; Internal error:
;;; ** There is no package with the name SB-EXT.

coming back to 652a10d fixes the issue

Since there have been a few issues (e.g. #14 and #15) and various complications with the inclusion of the devices interface, I think it could make sense to refactor into "core" and "extras" libraries.

The original intent was to keep the OSC protocol encoding/decoding relatively simple and contained to a single file if possible. The networking layer could be independent. I still think can work, so I've reverted and/or refactored with this in mind.

The core library will remain here and the other-than-core can be found at or near https://github.com/zzkt/osc-devices

core features

• simple functional style interface
• complete protocol coverage
• compatibility with supercollider and pd (at least)
• runs on as many CL implementations as possible
• reasonable error handling & reporting

non-core features

• networking API (c.f. liblo or devices)
• introspection and/or reflection
• etc

There are a few changes from @byulparan as part of cl-collider to improve supercollider interop

fix and/or reassemble the CI as seen near https://github.com/zzkt/osc/blob/endless/.github/workflows/ci.yaml (and probably some decent tests)

as of JAN 2024

• sbcl on windows-latest
• sbcl on ubuntu-latest
• sbcl on macos-latest
• ccl-bin on windows-latest
• ccl-bin on ubuntu-latest
• ccl-bin on macos-latest
• ecl on ubuntu-latest
• ecl on macos-latest
• allegro on ubuntu-latest

e.g. encoding a :symbol which is unbound, or has no symbol-value will cause an error

;; osc-examples.lisp

(osc-examples::osc-send-test #(127 0 0 1) 6668)

The function OSC:ENCODE-MESSAGE is undefined.
   [Condition of type UNDEFINED-FUNCTION]

;; osc-device-examples.lisp

(defparameter *osc-server* (make-osc-server :protocol :udp
                                            :debug-mode t))

(boot *osc-server* 57127)

There is no class named OSC::INET-SOCKET.
   [Condition of type SB-PCL:CLASS-NOT-FOUND-ERROR]

I tested on macOS(12.6.1) / SBCL(2.2.10.32-eefe83e36) / OSC(osc-20221106-git from quicklisp).
Thanks for works!

Based on the discussion and analysis on cliki about the LLGPL (in particular Eli Greenbaum's detailed examination of the LLGPL) I think it makes sense to change the licence to GPLv3 (or later).

If there is anyone who has contributed to the library that objects to this please let me know.

encode-data checks for float (using typecase), and encodes it using encode-float32. However, if a double float is passed to encode-data, it will also match the float clause and will be encoded as a single-float.

Depending on the implementation, this may give the correct result, throw an error, or silently fail with the wrong result. (That's what happened to me)

A simple fix would be to change the typecond clause in encode-data (and encode-typetags) from float to single-float. This could later be complemented by a check for double-float, calling encode-float64.

Another possible simple fix would be to coerce the value to a single-float before passing it to encode-float32.

Seems like ~20 years should be long enough for version 0.x (fist commit was circa 2004) so perhaps time for a slightly significant increment...

Looks like the commit history went a bit wonky during 67118a4 when merging changes from @jamieforth (maybe rebase and/or fix it 'some day')

I met this error

(ql:quickload :osc)
(osc::decode-float32 #(127 255 255 255))

get error below

The value
-2147483649
is not of type
(SIGNED-BYTE 32)
[Condition of type TYPE-ERROR]

It seems wrong covert on osc::decode-int32.
(osc::decode-int32 (osc::encode-int32 2147483647)) ;; result is -2147483649

I think correct value of (osc::decode-int32 #(127 255 255 255)) is 2147483647

I test it other language and I got 2147483647.

;;; guile
(bytevector->sint-list
 (uint-list->bytevector '(127 255 255 255) (endianness big) 1)
 (endianness big) 4)

#include <stdio.h>
#include <string.h>

int main(int argc, char** argv) {

  char bv[4] = {127, 255, 255, 255};
  int result;
  memcpy(&result, bv, sizeof(result));

  printf("decode value: %d\n", htonl(result));
  
  return 0;  
}