JAudioLibs and AudioOps

75 views
Skip to first unread message

Didier Villevalois

unread,
Oct 21, 2012, 9:57:56 AM10/21/12
to jaudi...@googlegroups.com
[Sorry if I double-posted, I was not sure the first post was successful!]

Hello,

I would need to use JAudioLibs and AudioOps in an DJ application specialized for social dances that I'm working on.

I have a bunch of questions:

- Do you have nearby plans to release AudioOps as part of JAudioLibs ?
- Will you provide a git repo for JAudioLibs ?
- Would you mind I mavenized the projects ?

I'm willing to do the extraction work of AudioOps from praxis, create a git repo (that you can put back on googlecode) and do the mavenization work. Just tell me and I'll do it.

Thanks. Didier.

Neil C Smith

unread,
Oct 22, 2012, 6:06:10 AM10/22/12
to jaudi...@googlegroups.com
Hi,

On 21 October 2012 14:57, Didier Villevalois <pti...@gmail.com> wrote:
> [Sorry if I double-posted, I was not sure the first post was successful!]

That's because first posts to the Praxis list are moderated. This
list was meant to be set the same - have now made sure it is!

> I would need to use JAudioLibs and AudioOps in an DJ application specialized
> for social dances that I'm working on.
>

Sounds interesting, and getting JAudioLibs into more projects will be great! :-)

> I have a bunch of questions:
> - Do you have nearby plans to release AudioOps as part of JAudioLibs ?

Yes. It's been on my todo list too long! The AudioOps release was
held up by some refactoring work, and I didn't want to release it
separately until that was done. The API is probably stable enough now
for a separate release.

Most of the code is ported from other Java audio projects - the idea
is to try and build a repository of DSP code that is reusable without
huge dependencies. Out of interest, any you particularly want to use?
Anything missing for you at the moment?

> - Will you provide a git repo for JAudioLibs ?

Unlikely for me. JAudioLibs is developed integrally as part of
Praxis, though always with the intention of being usable elsewhere.
Praxis, for a couple of historical reasons (NetBeans & Google Code),
uses Mercurial and at the moment I see little reason to change.

> - Would you mind I mavenized the projects ?

Not at all. Maybe need a discussion about how versioning is marked,
particularly before I do an actual release? That will happen before
the end of the year, possibly in the next month.

> I'm willing to do the extraction work of AudioOps from praxis, create a git
> repo (that you can put back on googlecode) and do the mavenization work.
> Just tell me and I'll do it.

Happy if you want to do that. I'm not against the idea of a separate
git repo for all the JAudioLibs code, either. Will need some thinking
about the best way of keeping the code in the Praxis repo in sync with
it.

You should also take a look at Pipes, which is the other library that
will see a separate release this year. It is the missing link between
audio servers and audio ops, and deals with audio routing. Of course,
you don't have to use it - I deliberately wanted the three concerns
(audio IO, audio DSP and audio routing) to be kept separate.

Best wishes,

Neil

--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net

Praxis LIVE - open-source, graphical environment for rapid development
of intermedia performance tools, projections and interactive spaces -
http://code.google.com/p/praxis

OpenEye - specialist web solutions for the cultural, education,
charitable and local government sectors - http://openeye.info

Didier 'Ptitjes' Villevalois

unread,
Oct 22, 2012, 10:04:45 AM10/22/12
to jaudi...@googlegroups.com
Hello,

On lun., 2012-10-22 at 11:06 +0100, Neil C Smith wrote:
> On 21 October 2012 14:57, Didier Villevalois <pti...@gmail.com> wrote:
> > - Do you have nearby plans to release AudioOps as part of JAudioLibs ?
>
> Yes. It's been on my todo list too long! The AudioOps release was
> held up by some refactoring work, and I didn't want to release it
> separately until that was done. The API is probably stable enough now
> for a separate release.

Cool!

> Most of the code is ported from other Java audio projects - the idea
> is to try and build a repository of DSP code that is reusable without
> huge dependencies. Out of interest, any you particularly want to use?
> Anything missing for you at the moment?

I describe my needs below. However I still do not envision the whole
stuff. I really need to have JAudioLibs in my IDE (which means
maven-packaged project, sources and javadocs) to get the big picture in
mind.

> > - Will you provide a git repo for JAudioLibs ?
>
> Unlikely for me. JAudioLibs is developed integrally as part of
> Praxis, though always with the intention of being usable elsewhere.
> Praxis, for a couple of historical reasons (NetBeans & Google Code),
> uses Mercurial and at the moment I see little reason to change.

I see that the googlecode site has no "source" tab activated. Do you
still extract JAudioLibs' code from Praxis repo ? I would be glad if
there was a repo just for JAudioLibs. That way we can clone (talking the
git way, don't know mercurial), branch and make pull requests. This is
far easier to manage an open-source project.

BTW, I'm quite sure googlecode handles git repos.

> > - Would you mind I mavenized the projects ?
>
> Not at all. Maybe need a discussion about how versioning is marked,
> particularly before I do an actual release? That will happen before
> the end of the year, possibly in the next month.

Yep! I thought that maybe JNAJack could be versionned separately from
JAudioLibs. Here is what I tought:

org.jaudiolibs.jnajack:jnajack in a separate project

org.jaudiolibs:jaudiolibs-servers
org.jaudiolibs:jaudiolibs-ops
org.jaudiolibs:jaudiolibs-pipes

together and sharing version:

jaudiolibs
- jaudiolibs-servers
- jaudiolibs-ops
- jaudiolibs-pipes

Maybe we could work together if you intend to do the release in the
month. So that the projects are first released with maven POMs. That way
it could go directly into maven central repositories.

> > I'm willing to do the extraction work of AudioOps from praxis, create a git
> > repo (that you can put back on googlecode) and do the mavenization work.
> > Just tell me and I'll do it.
>
> Happy if you want to do that. I'm not against the idea of a separate
> git repo for all the JAudioLibs code, either. Will need some thinking
> about the best way of keeping the code in the Praxis repo in sync with
> it.

Why do you need to replicate the code of JAudioLibs in Praxis if
JAudioLibs is well packaged ?

> You should also take a look at Pipes, which is the other library that
> will see a separate release this year. It is the missing link between
> audio servers and audio ops, and deals with audio routing. Of course,
> you don't have to use it - I deliberately wanted the three concerns
> (audio IO, audio DSP and audio routing) to be kept separate.

In fact, I included in my thinking pipes but forgot to tell you too :)

So that you understand what I need, I'll explain you a bit of my
project, if you don't mind:

Have two player a main one and a monitoring/pre-listen one :
- The main player uses a queue and only the queue (can't be manipulated
in another way during a DJ session). The queue supports
begin/end/fade-in/fade-out cues for each queue item.
- The monitoring player is a standard player (can play/stop/next/...).

I must send the outputs of those players to two different stereo
outputs. An additional requirement is that some DJ sound cards don't
have a pair of stereo lines but one line of 4 channels. So I have to
make the mux myself.

So I would only use pipes (obviously), the gain op (for player gain and
fades), and audioservers for the final mux.

I intend to later take profit of the other capabilities of JAudioLibs.
For instance, if I add an additional Sample player, I would also need to
mix the main output.

Best regards,
Didier.

Neil C Smith

unread,
Oct 22, 2012, 1:28:09 PM10/22/12
to jaudi...@googlegroups.com
Hi,

On 22 October 2012 15:04, Didier 'Ptitjes' Villevalois
<pti...@gmail.com> wrote:
> I see that the googlecode site has no "source" tab activated. Do you
> still extract JAudioLibs' code from Praxis repo ? I would be glad if
> there was a repo just for JAudioLibs. That way we can clone (talking the
> git way, don't know mercurial), branch and make pull requests. This is
> far easier to manage an open-source project.
>

It will require a reversal of the way the project is currently built
and managed. The way it's currently set up is the easiest way for me
to manage as a solo project (see point below). However, if JAudioLibs
gains traction and third-party contributions then I agree with you.

> BTW, I'm quite sure googlecode handles git repos.
>

It does *now*. Neither Google Code or NetBeans handled git when the
project began.

> Yep! I thought that maybe JNAJack could be versionned separately from
> JAudioLibs. Here is what I tought:

Actually, I was planning on removing the current joint versioning, and
doing it independently for each. Presumably Maven can handle
dependency / version resolution well?

Should be -

org.jaudiolibs.jnajack:jnajack

org.jaudiolibs:jaudiolibs-servers API
org.jaudiolibs:jaudiolibs-servers JavaSound
org.jaudiolibs:jaudiolibs-servers Jack

org.jaudiolibs:jaudiolibs-ops (not currently split between API and
implementations - probably will be by release)

org.jaudiolibs:jaudiolibs-pipes

> Maybe we could work together if you intend to do the release in the
> month. So that the projects are first released with maven POMs. That way
> it could go directly into maven central repositories.

Possibly. I need to look into Maven further - not something I've
used. Also, I've just heard I have a big deadline for 23rd Nov, so
it's likely to be the week after that at the earliest.

> Why do you need to replicate the code of JAudioLibs in Praxis if
> JAudioLibs is well packaged ?
>

This is key to why JAudioLibs does not yet have its own repo. Praxis
is a NetBeans platform based application, and uses its module system
(think OSGI if you're not aware of it, though it has some
differences). Therefore all the JAudioLibs code is currently built as
NetBeans modules - you'll notice this if you look inside the manifest
of one of the JAudioLibs JARs. The source drop on the JAudioLibs page
removes the build scripts for this.

It is possible to build the JAudioLibs JARs separately, and then wrap
them in NetBeans modules. It just makes my build and development
process more convoluted. Or I have to manage the code in two repos
and keep them synced. Hence the current situation, where the code is
developed as part of Praxis and extracted, until there is more value
in it being developed separately.

Didier 'Ptitjes' Villevalois

unread,
Oct 25, 2012, 8:32:02 AM10/25/12
to jaudi...@googlegroups.com
Hi Neil,

I hope your deadline has went well. I took a little time to answer you
as you had other concerns and also to make some Maven/NetBeans
experiments.

And I'm very happy with the result. I can announce you that Maven can
generate jar modules compatible with NetBeans requirements and that also
fit standard Maven development model.

So I took the liberty to push my work on github:

https://github.com/ptitjes/jnajack
https://github.com/ptitjes/jaudiolibs

I'll be happy to make them cloning your google-code repos when you'll
open it.

So there is configuration stuff in the pom.xml files to generate the
NetBeans module manifest files. Maven generates dependencies and some
other things in the manifest. Also each sub-project have an additional
src/main/nbm/manifest.mf to specify additional properties (such as
AutoUpdate-Show-In-Client and other stuff not generated by
maven-nbm-plugin).

I double-checked what the generated MANIFEST.MF files contains against
what you have in you binary releases. It seems to be sound and complete.
(In fact, Maven also adds some cool stuff like
OpenIDE-Module-Display-Category, OpenIDE-Module-Name, and
OpenIDE-Module-Short-Description)

I set up the jaudiolibs project so that versions can be independent for
the three parts of the project (audioservers, audioops and audiopipes).

I temporarily let the packages and projects be named:
org.jaudiolibs.audioservers.*
jaudiolibs-audioservers-*

so that we can synchronize you action in Praxis to rename them:
org.jaudiolibs.servers.*
jaudiolibs-servers-*

Also, I found a Maven plugin that seems to automate the deployment of
netbeans modules
http://mevenide.codehaus.org/m2-site/netbeans-deploy-plugin/deploy-mojo.html
I don't know if that could help you, as I don't know NetBeans way of
doing things.

Finally, there seems to be a git plugin for Mercurial. See this blog
post:
http://www.hskupin.info/2009/12/18/synchronizing-a-mercurial-repository-with-git/

I hope you'll be happy with the result. Also I understand this makes a
lot of brand new tooling (git, maven) to learn/adapt and I really want
you to not feel pushed with all that.

However I'm eager that you give me the green flag to import the other
jaudiolibs stuff from Praxis. I'll do import them in my local repository
for now.

I'm available for any help you would need to understand all the Maven
stuff I've done.

Best regards,
Didier.

PS: Mini-tutorial to make you not waste your time :)

git clone https://github.com/ptitjes/jnajack.git jnajack
cd jnajack
mvn clean install
cd ..

git clone https://github.com/ptitjes/jaudiolibs.git jaudiolibs
cd jaudiolibs
mvn clean install
cd ..


Neil C Smith

unread,
Oct 25, 2012, 10:18:42 AM10/25/12
to jaudi...@googlegroups.com
Hi Didier,

On 25 October 2012 13:32, Didier 'Ptitjes' Villevalois
<pti...@gmail.com> wrote:
> I hope your deadline has went well.

Er ... it's next month! :-) Going OK so far. It is Praxis related,
but most of the work will involve video. I'll see what work I can do
with this before then, but may be minimal.

> I can announce you that Maven can
> generate jar modules compatible with NetBeans requirements and that also
> fit standard Maven development model.

Thanks for looking at that, but don't worry about it. I won't be
moving to Maven in Praxis' build for the foreseeable future, so
building a wrapper module around the basic JAR is going to be a better
approach. I don't want the NetBeans manifest stuff in the JARs in
case of any unforeseen issues.

> So I took the liberty to push my work on github:
>
> https://github.com/ptitjes/jnajack
> https://github.com/ptitjes/jaudiolibs
>
> I'll be happy to make them cloning your google-code repos when you'll
> open it.
>

OK. Why JNAJack separate, though?

> I set up the jaudiolibs project so that versions can be independent for
> the three parts of the project (audioservers, audioops and audiopipes).
>

Really need to think more about this. Am thinking that API changes
will be marked 1.0, 1.1, etc. With bug fixes marked with date - ie.
1.0.121025 Or something like that? Then versioning can be
independent across everything - important that version of audioserver
API doesn't have to be in sync with the implementation, etc.

> I temporarily let the packages and projects be named:
> org.jaudiolibs.audioservers.*
> jaudiolibs-audioservers-*
>
> so that we can synchronize you action in Praxis to rename them:
> org.jaudiolibs.servers.*
> jaudiolibs-servers-*
>

I'm not planning on renaming anything. I think that might be a
misunderstanding from my previous email? I was just making the point
that what are separate plugins in Praxis should be separate Maven
projects, so people can pull in only what they need. Which is like
you've set it up anyway.

Having said that, I wasn't planning on splitting Pipes up into API and
implementation. Unlike the other libraries, it isn't planned to grow
with further / alternative implementations.

> I hope you'll be happy with the result. Also I understand this makes a
> lot of brand new tooling (git, maven) to learn/adapt and I really want
> you to not feel pushed with all that.

Managing the JAudioLibs code separately in its own repo with git /
maven isn't much of an issue once I get the time to look at it
properly. There's already something in Praxis that I had to fork that
uses Maven to build a JAR which I then wrap.

> However I'm eager that you give me the green flag to import the other
> jaudiolibs stuff from Praxis. I'll do import them in my local repository
> for now.

What are you missing? Seems to all be there.

>
> I'm available for any help you would need to understand all the Maven
> stuff I've done.
>

I may take you up on that! :-)

Neil C Smith

unread,
Dec 4, 2012, 2:21:27 PM12/4/12
to jaudi...@googlegroups.com
Hi Didier,

Just a short note that I started looking into this last week. I'm
using the project at http://code.google.com/p/jaudiolibs/ to host.
This will at some point become the main project page for JAudioLibs
too, as Google Code doesn't allow project renaming. Doing it this way
means I can also keep the current JavaDoc up for now.

There is nothing in the default repository at the moment, but there
are git repositories for JNAJack and AudioServers. I will look to get
the AudioOps and Pipes code up there (again in separate repositories)
this week.

Slowly getting my head around Maven. I built the projects from
scratch rather than forking what you'd done, so hopefully it's all
building OK. Next job is to work out the best way to do release from
these.

I will sync any changes I make in Praxis to this site over the next
month. Once the next Praxis LIVE release is out, I'll switch to using
this for the main development of the JAudioLibs code.

Best wishes,

Neil

Neil C Smith

unread,
Dec 5, 2012, 12:48:12 PM12/5/12
to jaudi...@googlegroups.com
Hi All,

OK. A quick follow-up note that the code for AudioOps and Pipes are
now up as well.

http://code.google.com/p/jaudiolibs/source/browse?repo=audioops
http://code.google.com/p/jaudiolibs/source/browse?repo=pipes

AudioOps covers most of the DSP code that is in use in Praxis,
including filters, delays, chorus, reverb, etc. They are all based
around a single interface and no other dependencies so should be
easily reusable. Licence is GPL w/CPE, so usable in non-GPL projects
as well. Code comes from a variety of sources - credits in the code.

Pipes is the 'missing link' between AudioServers and AudioOps,
providing a simple way to route and process audio. Combining the
three libraries provides a graph-style / UGen audio processing
library, and the basis of Praxis' audio code. Code is again GPL w/CPE
(there are a couple of wrong headers which I've just noticed and will
fix ASAP). Documentation is lacking at the moment, but hopefully not
too hard to fathom - you can check the Praxis repo too to see how it's
used there.

Further documentation and a proper release will come, but the code
should be usable.

Best wishes,

Neil
Reply all
Reply to author
Forward
0 new messages