Extensions

[Shinmera]

File Formats

• FLAC
• MPT (tracker files)
• MP3
• OGG/Vorbis
• OGG/Opus
• QOA
• WAVE

Output

• AAudio
• Alsa
• CoreAudio
• DirectSound
• Jack
• OpenAL
• OpenSL
• OSS
• out123
• PipeWire
• PulseAudio
• SDL2 (done, but broken)
• WASAPI
• WinMM (done, but broken)
• XAudio2 (done, but broken)

Input

• AAudio
• Alsa
• CoreAudio
• DirectSound
• Jack
• OpenAL
• OpenSL
• OSS
• PipeWire
• PulseAudio
• SDL2
• WASAPI
• WinMM
• XAudio2

[lane-s]

Hello 👋 @Shinmera, great work so far on this library! I'm interested in helping out in this area (in particular with improving the CoreAudio extension [WIP 🛠️] ), but I feel like I'm not understanding some high-level ideas about how the extensions should be structured/used.

I'm not sure how, as a user of the library, I should go about enabling an extension. It feels a bit like this problem:
https://stackoverflow.com/a/42639621

And this project is also trying to solve a similar problem:
https://github.com/tfeb/conduit-packages

Also maybe it's ok to just leave it up to the client to define common interfaces that might combine different extensions, but it would be nice to include some example of that just to show how things can come together. I'd be interested to hear your thoughts on this.

[Shinmera]

Sorry, I have no idea what you're asking, really?

[lane-s]

@Shinmera Sorry, I'll try to explain the issue more- the answer could also easily be that I'm overthinking it.

• cl-mixed defines one core system and then a bunch of extension systems
• The core system defines base classes and generic functions, while the extensions define subclasses/implementations for the generics

My question is: how should a client of the library go about using these systems together? You can't just :use everything because there will be name conflicts, so the client needs to know which symbols to import from an extension and which ones to import from the core. Maybe, that's fine, but my intuition was that there should be some additional interface layer.

For example, in my project I attempted to make this sort of interface using define-package from conduit-packages. This is a language extension that lets us make a package that easily re-exports" symbols from one or more other package.

(define-package :audio-interface
  (:use :cl)
  (:extends/excluding :org.shirakumo.fraf.mixed
                      #:byte-position ;; conflicts with symbol from :cl 
                      #:drain              ;; abstract base class
                      #:list-devices). ;; generic definition which we'll replace with a concrete one
  (:extends/excluding :org.shirakumo.fraf.mixed.coreaudio
                      #:list-devices). ;; concrete implementation
  (:local-nicknames
   (#:mixed :org.shirakumo.fraf.mixed)
   (#:mixed-coreaudio :org.shirakumo.fraf.mixed.coreaudio))
  (:export #:list-devices))
(in-package :audio-interface)

(defun list-devices () ;; common interface that can choose concrete implementation
  (mixed:list-devices
   (make-instance 'mixed-coreaudio:drain)))

In this example, I could already call (audio-interface:make-pack) because that symbol is re-exported from the interface package.

[Shinmera]

you seem to be fundamentally confused about common lisp, not really this library. there's no need to :use anything, and in general you should not, anyhow.

Just refer to the symbol by its full name: (make-instance 'org.shirakumo.fraf.mixed.coreaudio:drain), you don't have to use, import, or anything.

[lane-s]

it's true that I'm new to CL and wasn't aware that that's the philosophy. I still think there may be some value in providing a common interface that could be configured to use different extension modules, but it's not worth spending energy on until I have a better idea of what I'm going for (I'm currently just doing some exploratory programming). Anyway, thanks for you reply.