Direction of JAudioLibs, integration with Beads
Ollie
offline and over at Beads. I'm planning on incorporating JAudioLibs
into Beads and hoping it's going to grow as a good general purpose
realtime audio IO tool for a range of situations. I agree that it
would be nice if it is service based but I don't think that's
essential. The ideal thing for me would be for a developer to be able
to drop in and out different dependencies, either passing on the
driver choice to the end user or fixing it in their code, depending on
context.
Regarding how this gets incorporated into Beads. Following our
discussion about the relationship between AudioContext and AudioIO I'm
considering just re-collapsing the two into one class again, an
abstract base class with different implementations. That resolves all
of the issues we've just been discussing. In fact, AudioContext could
be non-abstract, but only usable as a non-realtime environment, then
its various subclasses could provide different realtime IO.
As I've been saying I also hope to remove all direct JavaSound
dependencies from Beads which means hitting the structure of the
various classes involved in loading sample data from files. I'll be
refactoring that soon. I'm wondering if JAudioLibs does, or intends
to, do file stuff as well as IO?
Great work!
Ollie
Neil C Smith
Thanks for moving discussion on to this list.
On 14 November 2011 05:15, Ollie <ol...@icarus.nu> wrote:
> Hi Neil / JAudioLibs, picking up on the discussion we've been having
> offline and over at Beads. I'm planning on incorporating JAudioLibs
> into Beads and hoping it's going to grow as a good general purpose
> realtime audio IO tool for a range of situations.
That's the plan! Well, *a* plan. :-) There are a number of other
JAudioLibs sub-projects that are in the works, including the AudioOps
project which is an attempt at a LADSPA-esque API in Java for sharing
of audio effects. This isn't released separately yet, as the API's
going through a couple of changes as I prepare for a Praxis beta, but
hopefully that might also be of interest for you.
Incidentally, feel free to suggest any other useful sub-projects. I
do also have the jaudiolibs.org domain - at some point I may even put
something useful on it! :-)
> I agree that it
> would be nice if it is service based but I don't think that's
> essential. The ideal thing for me would be for a developer to be able
> to drop in and out different dependencies, either passing on the
> driver choice to the end user or fixing it in their code, depending on
> context.
>
I definitely want to bring in a minimal service registration process
at some point in the near future, though that will never preclude
direct instantiation of any of the audio server implementations. How
important this is depends on the application - whether the choice of
backend is made by the developer or the user - though there are
benefits to decoupling for both. I'd rather have a minimal service
API that covers the bulk of cases included than force everyone to roll
their own (and it's essential for Praxis anyway).
> Regarding how this gets incorporated into Beads. Following our
> discussion about the relationship between AudioContext and AudioIO I'm
> considering just re-collapsing the two into one class again, an
> abstract base class with different implementations. That resolves all
> of the issues we've just been discussing. In fact, AudioContext could
> be non-abstract, but only usable as a non-realtime environment, then
> its various subclasses could provide different realtime IO.
>
This depends a little bit on whether you're happy to have a dependency
on the JAudioLibs API in your public facing code? If yes, then I'd
suggest having AudioContext as a concrete class that implements
AudioClient. AudioContext could contain some helper code to connect
itself to an AudioServer automatically (ie. start() could still work),
but it also wouldn't preclude someone creating the AudioServer
themselves and passing in the Beads AudioContext directly. You
wouldn't need to do anything else then to ensure that Beads worked
with any AudioServer implementation.
Having multiple AudioContext subclasses would probably be the way to
do it if you wanted to keep the JAudioLibs stuff more hidden, but it
does add an extra layer of abstraction, and means that any new
AudioServer implementations would need to be wrapped (well, I suppose
you could have one AudioClientAudioContext - how's that for a terrible
class name?)
> As I've been saying I also hope to remove all direct JavaSound
> dependencies from Beads which means hitting the structure of the
> various classes involved in loading sample data from files. I'll be
> refactoring that soon. I'm wondering if JAudioLibs does, or intends
> to, do file stuff as well as IO?
>
That would make a great sub-project! :-) However, I have to say it's
not a huge priority for me personally at the moment - all my use cases
are JavaSE currently. I'm planning on making some AudioOps that do
sample playback, though, so it might be useful to consider. It would
also be good to get an AudioServer implementation that reads and
writes to and from files.
> Great work!
>
Thanks! :-D
Best wishes,
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net