Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request for JACK/LV2 "CV" support #810

Open
mxmilkb opened this issue Dec 3, 2019 · 16 comments
Open

Feature request for JACK/LV2 "CV" support #810

mxmilkb opened this issue Dec 3, 2019 · 16 comments
Labels

Comments

@mxmilkb
Copy link

@mxmilkb mxmilkb commented Dec 3, 2019

The JACK system (along with the LV2 plugin format) has support for passing audio rate parameter control "CV" signals between apps (and plugins) for uses including gate/triggers and modulation.

This port type ("CV" in JACK, "CVPort" in LV2) has more recently started seeing support in various software projects. More details on the subject can be found on this post.

Could an input/output method for this data stream become a thing in a future iteration of Pd?

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 3, 2019

do you have an idea how the interface should look like?

(although i have to admit that i totally fail to see the advantage of an "audio-rate CV stream" over an "audio stream")

@mxmilkb

This comment has been minimized.

Copy link
Author

@mxmilkb mxmilkb commented Dec 4, 2019

On the outside, it would present as a JACK CV port, which shows up differently in Carla;

image

On the inside, either the same as an adc~ or maybe slightly different?

(I think generally people find the distinction handy because the former might be a constant (DC-like) level, where the latter is expected to cross 0 at some point/be listened to/be "safe(r)" to route to speakers.)

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 4, 2019

well, jack doesn't know anything about "speakers". your computer might just be a small part in a bigger (physical) modular synth, where the signal you send to system:playback_1 is really just a trigger signal that goes into a step sequencer.

but anyhow, the real problem is, that Pd supports a number of different audio backends, and jack is only one of them. any solution would need to provide a consistent behaviour across all platforms and audio backends.

afaict, you can connect a CV-outlet to an audio-inlet (or vice-versa, as your screenshot illustrates) anyhow, so there already is an input method for this thing in the current iteration and nothing to act upon. Pd doesn't provide a way for the user to name each of it's jack ports, so you have a hard time figuring out which port does what regardless of support for CV or not.

@umlaeute umlaeute added the feature label Dec 4, 2019
@mxmilkb

This comment has been minimized.

Copy link
Author

@mxmilkb mxmilkb commented Dec 26, 2019

My screenshot doesn't illustrate direct connection between audio and CV ports. Dark CV port to dark CV port, light audio port to light audio port.

JACK does "know" about speakers in the sense that JACK client and connection manager Carla (developed by the maintainer of JACK) knows not to allow the user to connect a CV port directly to an audio port, specifically because CV signal is a) not made to be listened to (on speakers) and b) can damage speakers. (IIRC you can connect audio to CV in Carla).

The boundary between JACK CV and hardware interfaces is somewhat fuzzy still (even with Carla), though I'm sure will be receiving focus in 2020.

The advances JACK has been able to make, in both terms of port metadata for conveying name (and min/man/range) and the influence of LV2 CV data, has certainly set it apart over other audio systems.

In relation to other backends; I guess in terms of the Pd level of abstraction, the relation between an "audio-rate CV stream" over an "audio stream" being nothing, there should be no problem in continuing the same behaviour, i.e., if someone uses audio as CV in Pd, then they can continue sending it out to the world using their same non-JACK backend setup.

For users who do use JACK though, the possibility of setting the corresponding CV "bit" for that output to the JACK system would certainly be handy (though I have no thought as to how Pd might handle that (or range/name/etc. port metadata) in relation to dac~ or whatnot).

(Ultimately "JACK port metadata support" is an alternative issue name.)

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 26, 2019

My screenshot doesn't illustrate direct connection between audio and CV ports. Dark CV port to dark CV port, light audio port to light audio port.

oh. so zlfo produces a sine-wave which is not an audio signal...that's beyond me...

anyhow: will the CV-extension make it into jack1?
i strongly believe that Pd's JACK support should allow to transparently switch between both...

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 26, 2019

anyhow: i guess the best solution would be an external that handles the JACK-metadata.
i don't know if this is possible at all...

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 26, 2019

iirc, i also did a PR once to allow writing "audio backends" as externals, which might provide a route for this problem...

@mxmilkb

This comment has been minimized.

Copy link
Author

@mxmilkb mxmilkb commented Dec 26, 2019

So I can reply regarding zlfo, can you define your use of "audio signal"? :)

JACK1 is in maintenance mode, see the Past, Present and Future of the JACK Audio Connection Kit talk by falkTX at Sonoj earlier this year.

JACK2 was slow to get port metadata, something that originated in JACK1.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 26, 2019

JACK1 is in maintenance mode

so?

JACK2 was slow to get port metadata, something that originated in JACK1.

as i said: we want to be able to switch transparently (at compile time and runtime) between the two of them. on any platform. regardless which one is the library that lacks functionality...

anyhow: i still don't see the point of "audio-rate CV" in the first place, at least in an environment like Pd: it's one of Pd's main strengths to make no semantic discrimination between "same types".

@mxmilkb

This comment has been minimized.

Copy link
Author

@mxmilkb mxmilkb commented Dec 26, 2019

so?

Maybe you didn't know? :)

we want to be able to switch transparently (at compile time and runtime) between the two of them. regardless which one is the library that lacks functionality...

To be clear, both JACK1 and JACK2 now support metadata on ports to denote an audio port is a "CV" port. It was only more recently that JACK2 got support.

i still don't see the point of "audio-rate CV" in the first place, at least in an environment like Pd: it's one of Pd's main strengths to make no semantic discrimination between "same types".

This is not so much about the Pd environment as it is about the user experience of the interface between a Pd environment and a JACK environment (plus the general expressive options that open up with inter-app virtual CV patching).

adcv~ and dacv~?

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Dec 26, 2019

adcv~ and dacv~ ?

these sound like splendid externals.

i just doubt that Pd should provide very specific i/o of debatable merits that none of the other audio backends support.

what would those CV objects do when using ALSA, OSS, CoreAudio, MMIO, ASIO?

@mxmilkb

This comment has been minimized.

Copy link
Author

@mxmilkb mxmilkb commented Dec 26, 2019

externals

If the Pd internal JACK code is enabled with via a flag / USEAPI_JACK, does it not make some sense to enable metadata at that level?

what would those CV objects do when using ALSA, OSS, CoreAudio, MMIO, ASIO?

Fallback to acting as adc~ and dac~.

@umlaeute

This comment has been minimized.

Copy link
Contributor

@umlaeute umlaeute commented Jan 1, 2020

Fallback to acting as adc~ and dac~

so what would come out of the following patch with JACK-metadata and without:

[osc~ 440]
|
+------------+
|            |
[dac~ 1]     [dacv~ 1]

If the Pd internal JACK code is enabled with via a flag / USEAPI_JACK, does it not make some sense to enable metadata at that level?

not unless we can find a proper way to interact with this metadata on a patch-level (that also makes sense for other audio backends)

@mxa

This comment has been minimized.

Copy link
Contributor

@mxa mxa commented Jan 1, 2020

Maybe it makes more sense to make [dac~] and [adc~] understand some kind of label messages to set Jack port metadata which other audio backends just ignore?

btw. there seems no canonical way of naming Jack ports.
Jacks own ports are playback_1, playback_2 and capture_1, capture_2
Pure Data calls them input0, input1 and output0, output1
The PulseAudio Source calls them front-left, front-right
Bitwig has names like Stereo Input-L

For spacing all possibilities are there: spaces, no spaces, dashes, underscores
Some count from 0, some from 1
Capitalized or not

@mxmilkb

This comment has been minimized.

Copy link
Author

@mxmilkb mxmilkb commented Jan 1, 2020

there seems no canonical way of naming Jack ports.

Maybe I'm missing an understanding but does not UUID and metadata pretty names assist with port naming? https://jackaudio.org/metadata

@nicolasdanet

This comment has been minimized.

Copy link

@nicolasdanet nicolasdanet commented Jan 2, 2020

It could be global messages that set flags (at application level) used when opening the JACK ports?

[ ; pd metadata input 1 cv 1 (
[ ; pd metadata input 1 minimum 0 (
[ ; pd metadata input 1 maximum 10 (
[ ; pd metadata output 2 name Foo (
[ ; pd metadata reset (

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.