-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 23:11, Miller Puckette wrote:
Hi all,
Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm
cool.
I'm ready to start hacking on 0.44. The most urgent thing seems to be for me to go back and work on the audio system (and perhaps tweak MIDI a bit more too).
i have a project lying on my hardisk for >1 year (iirc, shortly before the 0.32.0 release), that is related to that: separating the audio system(s) from Pd-core.
background: currently Pd supports a number of audio-backends. while these backends are mainly separated into several source files (e.g. s_audio_alsa.c for ALSA), there is a lot of theoretically backend-agnostic code (s_audio, s_midi, s_main) cluttered with "#ifdef USEAPI_ALSA" and the like. this makes the current code badly readable and thus maintainable, it also makes it hard to add new audio systems as backends (and the more you add, the more complicated the codebase gets).
more background: currently all audio backends are linked to the main "Pd" binary. if your version of Pd is compiled for alsa, jack, OSS and portaudio (the default on debian), you have quite a number of dependencies. (as maintainer of the "puredata" debian package i prefer to keep necessary dependencies at a minimum).
furthermore, Pd supports outdated/deprecated backends like OSS (both audio and midi). in practice i haven't used OSS-midi for a number of years (and i doubt whether it is actually still supported by the mainline kernels), and i used OSS-audio only seldomly in very specific setups. from this i follow, that the majority of people have to fight their way through a lot of dead options that are more confusing than helpful, and which should probably be removed in most cases.
suggestion: so what i ended up doing, was separate the audio-backends from the pd-core code a bit more, in a similar way to how Pd's object registration works. the means that people could write new audio-backends and load them on-demand, just like "externals". it also means that Pd's non-audiosystem codebase has only a minimum of "#ifdef USEAPI_ALSA" (there's only one, when it comes to loading the "internal" audio-system at startup).
all this also applies to MIDI.
if there's interest, i could cleanup the patches (and make them work again with 0.43.3) and submit them for review.
if there's confusion, i could try to try again and explain what i want.
fgmasdr IOhannes
Le 04/07/2012 09:51, IOhannes m zmoelnig a écrit :
furthermore, Pd supports outdated/deprecated backends like OSS (both audio and midi). in practice i haven't used OSS-midi for a number of years (and i doubt whether it is actually still supported by the mainline kernels), and i used OSS-audio only seldomly in very specific setups.
i think oss-midi is still in ubuntu 12.04 and i'll still using it. oss-audio has been removed, but i'm still using it on older ubuntu release : i've got lot's better performance than alsa, and it's more plug and play than jack (obviously in some simple (stereo) setup).
cheers Cyrille
Also... I think OSS/MIDI is the only API now that lets you spit out arbitrary byes over the MIDI line -- all the others 'protect' you.
cheers Miller
On Wed, Jul 04, 2012 at 08:43:50PM +0200, Cyrille Henry wrote:
Le 04/07/2012 09:51, IOhannes m zmoelnig a écrit :
furthermore, Pd supports outdated/deprecated backends like OSS (both audio and midi). in practice i haven't used OSS-midi for a number of years (and i doubt whether it is actually still supported by the mainline kernels), and i used OSS-audio only seldomly in very specific setups.
i think oss-midi is still in ubuntu 12.04 and i'll still using it. oss-audio has been removed, but i'm still using it on older ubuntu release : i've got lot's better performance than alsa, and it's more plug and play than jack (obviously in some simple (stereo) setup).
cheers Cyrille
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-04 21:12, Miller Puckette wrote:
Also... I think OSS/MIDI is the only API now that lets you spit out arbitrary byes over the MIDI line -- all the others 'protect' you.
i'm not saying that i want to remove OSS-MIDI. i'm saying that i want to allow the user to remove OSS-MIDI, if they don't care for it.
to repeat: my patch is about adding more audio systems without touching the Pd-core. it's not about removing unused backends (though about making them optional)
fgamsdr IOhannes
On Jul 4, 2012, at 3:51 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-03 23:11, Miller Puckette wrote:
Hi all,
Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm
cool.
I'm ready to start hacking on 0.44. The most urgent thing seems to be for me to go back and work on the audio system (and perhaps tweak MIDI a bit more too).
i have a project lying on my hardisk for >1 year (iirc, shortly before the 0.32.0 release), that is related to that: separating the audio system(s) from Pd-core.
background: currently Pd supports a number of audio-backends. while these backends are mainly separated into several source files (e.g. s_audio_alsa.c for ALSA), there is a lot of theoretically backend-agnostic code (s_audio, s_midi, s_main) cluttered with "#ifdef USEAPI_ALSA" and the like. this makes the current code badly readable and thus maintainable, it also makes it hard to add new audio systems as backends (and the more you add, the more complicated the codebase gets).
more background: currently all audio backends are linked to the main "Pd" binary. if your version of Pd is compiled for alsa, jack, OSS and portaudio (the default on debian), you have quite a number of dependencies. (as maintainer of the "puredata" debian package i prefer to keep necessary dependencies at a minimum).
furthermore, Pd supports outdated/deprecated backends like OSS (both audio and midi). in practice i haven't used OSS-midi for a number of years (and i doubt whether it is actually still supported by the mainline kernels), and i used OSS-audio only seldomly in very specific setups. from this i follow, that the majority of people have to fight their way through a lot of dead options that are more confusing than helpful, and which should probably be removed in most cases.
suggestion: so what i ended up doing, was separate the audio-backends from the pd-core code a bit more, in a similar way to how Pd's object registration works. the means that people could write new audio-backends and load them on-demand, just like "externals". it also means that Pd's non-audiosystem codebase has only a minimum of "#ifdef USEAPI_ALSA" (there's only one, when it comes to loading the "internal" audio-system at startup).
all this also applies to MIDI.
if there's interest, i could cleanup the patches (and make them work again with 0.43.3) and submit them for review.
if there's confusion, i could try to try again and explain what i want.
I think this would be super valuable. libpd already has an implementation of parts of this idea, but making fully separate modules would be quite nice.
Have you talked with Peter Brinkmann at all? It would be nice to have these efforts synced up since they seem to have the same aim.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-31 04:11, Hans-Christoph Steiner wrote:
I think this would be super valuable. libpd already has an implementation of parts of this idea, but making fully separate modules would be quite nice.
Have you talked with Peter Brinkmann at all? It would be nice to have these efforts synced up since they seem to have the same aim.
i haven't talked with peter about this recently.
anyhow, i cleaned up the code a bit and pushed it to my github fork. check it out at [1].
currently MIDI has not been touched yet. also the preferences system (including startup flags) would need some slight modifications (e.g. use something like "-audioapi jack" rather than "-jack"; and use symbolic values ("audioapi: jack") in the .pdsettings file as well, rather than some weirdo numbers ("audioapi: 42" anyone?)
fgmasdr IOhannes
[1] https://github.com/umlaeute/pd-vanilla/tree/mediabackends
On Oct 31, 2012, at 5:48 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-31 04:11, Hans-Christoph Steiner wrote:
I think this would be super valuable. libpd already has an implementation of parts of this idea, but making fully separate modules would be quite nice.
Have you talked with Peter Brinkmann at all? It would be nice to have these efforts synced up since they seem to have the same aim.
i haven't talked with peter about this recently.
anyhow, i cleaned up the code a bit and pushed it to my github fork. check it out at [1].
What about taking it in this direction fully and making it possible to encapsulate the entire implementation for a given audio API in a single file? Then having it so s_audio.c is never modified. I think this is how it is for libpd, but I suppose that's easier there since libpd assumes there is some other program that will handle that stuff.
If there was a "register" function like how loaders are registered, and a very simple load path like a pre-defined folder like pd/lib, then pd -audioapi jack could just look for libaudio-jack.so there and load it. Or maybe it would be better to use the normal Pd search path. This would have the extra benefit of making it easy for people to distribute and use alternate implementations of the various APIs.
currently MIDI has not been touched yet. also the preferences system (including startup flags) would need some slight modifications (e.g. use something like "-audioapi jack" rather than "-jack"; and use symbolic values ("audioapi: jack") in the .pdsettings file as well, rather than some weirdo numbers ("audioapi: 42" anyone?)
The symbolic values make a lot of sense. We should leave in the code in Pd that reads the numeric values to support old files, but just have it always write out the symbol values. That should make the transition easier.
I tried this on Mac OS X, it builds and runs. Jack works, but portaudio does not. It does not give me any audio devices when I try to configure portaudio (see attached pic):
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-31 15:11, Hans-Christoph Steiner wrote:
What about taking it in this direction fully and making it possible to encapsulate the entire implementation for a given audio API in a single file? Then having it so s_audio.c is never modified.
in theory it is like that... in practice it's almost like that: the entire implementation of a given backend is contained within a single file. however, we still have references of the "built-in" audio-APIs in s_audio.c.
why?
well the target platform is Pd-vanilla.
i assume that it will take some time util Pd-vanilla itself will make all the "default" audio-backends as loadable modules. personally i would prefer it that way, but Pd has a history of keeping a number of functionality "built-in"; e.g. most objects could/should be loaded a runtime rather than being statically linked into the Pd binary ... see your attempts with the "vanilla" library)
so until then all audio-apis that "come with Pd" will continue to be "built-in". now all audio-apis have to register themselves, similar to how each objectclass has to register itself. if you check the code for how e.g. "metro" gets added, you'll see that the relevant code is called in metro_setup(), which in turn gets called by x_time_setup() which in turn gets called by conf_init(), pd_init(), sys_main(), main(). the same holds now true for audioapi_oss() (which registers the OSS API), getting called by audioapi_register(), sys_set_audio_api(),...
i could have moved the "#ifdef USEAPI_OSS" from s_audio.c to s_audio_oss.c. but given that s_audio_oss.c is only compiled with HAVE_OSS is set, it seemed easier to do it that way.
I think this is how it is for libpd, but I suppose that's easier there since libpd assumes there is some other program that will handle that stuff.
If there was a "register" function like how loaders are registered, and a very simple load path like a pre-defined folder like pd/lib, then pd -audioapi jack could just look for libaudio-jack.so there and load it. Or maybe it would be better to use the normal Pd search path. This would have the extra benefit of making it easy for people to distribute and use alternate implementations of the various APIs.
that's actually how it is (meant to be).
all audio-backends register themselves via a a call to "audioapi_new()". and that's about it.
i haven't implemented anything like default loading of binaries in a given path, since i think this another problem.
to dynamically add new backends at runtime, i'd suggest to re-use the library loading mechanism. #1 manually loading, using something like "-lib jackAPI". #2 automatic loading, by putting stuff into a special folder the content of which Pd will dlopen at startup (something like the ~/pd-externals/*-plugin/ mechanism for gui-plugins)
either way, Pd would just open jackAPI.pd_linux as an ordinary library/external but the setup function would register the new audio-api rather than new object-classes.
The symbolic values make a lot of sense. We should leave in the code in Pd that reads the numeric values to support old files, but just have it always write out the symbol values. That should make the transition easier.
yes definitely.
I tried this on Mac OS X, it builds and runs. Jack works, but portaudio does not. It does not give me any audio devices when I try to configure portaudio (see attached pic):
i'll check.
fgmasdf IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-31 15:36, IOhannes m zmoelnig wrote:
On 2012-10-31 15:11, Hans-Christoph Steiner wrote:
I tried this on Mac OS X, it builds and runs. Jack works, but portaudio does not. It does not give me any audio devices when I try to configure portaudio (see attached pic):
i'll check.
i checked on linux, and while i can reproduce the problem here, i have to say that i have exactly the same behaviour with Pd-vanilla (0.43.1test2, 0.43.2, 0.44.0test0).
i didn't really set out to eliminate bugs in the current implementation of backends, but rather to separate backends.
so...does portaudio device selection work on Pd-vanilla under OSX?
fgmasdr IOhannes
On Oct 31, 2012, at 10:42 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-31 15:36, IOhannes m zmoelnig wrote:
On 2012-10-31 15:11, Hans-Christoph Steiner wrote:
I tried this on Mac OS X, it builds and runs. Jack works, but portaudio does not. It does not give me any audio devices when I try to configure portaudio (see attached pic):
i'll check.
i checked on linux, and while i can reproduce the problem here, i have to say that i have exactly the same behaviour with Pd-vanilla (0.43.1test2, 0.43.2, 0.44.0test0).
i didn't really set out to eliminate bugs in the current implementation of backends, but rather to separate backends.
so...does portaudio device selection work on Pd-vanilla under OSX?
Audio works with Pd-vanilla 0.43-1 on Mac OS X using the build from Miller. That doesn't include jack support.
.hc
On Oct 31, 2012, at 10:36 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-31 15:11, Hans-Christoph Steiner wrote:
What about taking it in this direction fully and making it possible to encapsulate the entire implementation for a given audio API in a single file? Then having it so s_audio.c is never modified.
in theory it is like that... in practice it's almost like that: the entire implementation of a given backend is contained within a single file. however, we still have references of the "built-in" audio-APIs in s_audio.c.
why?
well the target platform is Pd-vanilla.
i assume that it will take some time util Pd-vanilla itself will make all the "default" audio-backends as loadable modules. personally i would prefer it that way, but Pd has a history of keeping a number of functionality "built-in"; e.g. most objects could/should be loaded a runtime rather than being statically linked into the Pd binary ... see your attempts with the "vanilla" library)
so until then all audio-apis that "come with Pd" will continue to be "built-in". now all audio-apis have to register themselves, similar to how each objectclass has to register itself. if you check the code for how e.g. "metro" gets added, you'll see that the relevant code is called in metro_setup(), which in turn gets called by x_time_setup() which in turn gets called by conf_init(), pd_init(), sys_main(), main(). the same holds now true for audioapi_oss() (which registers the OSS API), getting called by audioapi_register(), sys_set_audio_api(),...
i could have moved the "#ifdef USEAPI_OSS" from s_audio.c to s_audio_oss.c. but given that s_audio_oss.c is only compiled with HAVE_OSS is set, it seemed easier to do it that way.
Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module?
.hc
On 12/09/2012 17:31, Hans-Christoph Steiner wrote:
Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module?
(iirc) the current implementation allows us to overwrite/override a given backend by simply registering another backend of the same name. so es, you could provide a bug-fixed jack-implementation without touching the pd-code.
and of course, you could provide 3 different jack implementations (e.g. with different features sets) at the same time, by just using different API-names.
fgmadsr IOhannes
On Dec 9, 2012, at 1:19 PM, IOhannes m zmölnig wrote:
On 12/09/2012 17:31, Hans-Christoph Steiner wrote:
Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module?
(iirc) the current implementation allows us to overwrite/override a given backend by simply registering another backend of the same name. so es, you could provide a bug-fixed jack-implementation without touching the pd-code.
and of course, you could provide 3 different jack implementations (e.g. with different features sets) at the same time, by just using different API-names.
This sounds excellent. I'd like to include this in Pd-extended 0.44. Did you have a chance to look at the issue I reported in this thread where portaudio doesn't work on OSX?
.hc
-
Cyrille Henry -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Miller Puckette