non-session example client?

Post by James Morris
Hi,
I've seen reference (on linuxmusicians.com) to an example non-session
client written in c included in the non daw source but I can't find
such an example. If there was such an example it would help me add
support for non-session management into Petri-Foo. I could probably
work it out eventually but it could get messy.
Cheers,
James.

The C interface is file is nonlib/nsm.h in on the 'next' branch in git. You
can just copy it into your distribution. non-daw uses this interface, most
everything else uses the older C++ interface. See the patch to AZR3-jack (
http://non.tuxfamily.org/nsm/azr3-jack-1.2.3-nsm.patch) as a simpler
example of its use. Also, if you do just want to do it all from scratch,
the session-manager/jackpatch.c is an example of such a client.

Have fun! and don't hesitate to ask if you have any more questions.

James Morris

2012-07-04 00:30:45 UTC

The C interface is file is nonlib/nsm.h in on the 'next' branch in
git. You can just copy it into your distribution. non-daw uses this
interface, most everything else uses the older C++ interface. See the
patch to AZR3-jack
( http://non.tuxfamily.org/nsm/azr3-jack-1.2.3-nsm.patch) as a simpler
example of its use. Also, if you do just want to do it all from
scratch, the session-manager/jackpatch.c is an example of such a
client.
Have fun! and don't hesitate to ask if you have any more questions.

Thanks for the pointers. I'm slowly looking at the AZR code.

Could you mention nsm.h and jackpatch in the API documentation page?

I notice NSM says quite a lot about what applications should and should
not do but there is nothing about ports and auto-connecting. I know
jack session does not allow auto-connect, but some apps provide js with
a unconnected option but there is no way to tell jackpatch of this is
there? Was wondering if jackpatch could detect an
autoconnecting app and disconnect it before it brings up the saved
connections? Or would that cause problems for in certain situations?

Ta.

James.

J. Liles

2012-07-04 00:54:32 UTC

The C interface is file is nonlib/nsm.h in on the 'next' branch in
git. You can just copy it into your distribution. non-daw uses this
interface, most everything else uses the older C++ interface. See the
patch to AZR3-jack
( http://non.tuxfamily.org/nsm/azr3-jack-1.2.3-nsm.patch) as a simpler
example of its use. Also, if you do just want to do it all from
scratch, the session-manager/jackpatch.c is an example of such a
client.
Have fun! and don't hesitate to ask if you have any more questions.

Thanks for the pointers. I'm slowly looking at the AZR code.
Could you mention nsm.h and jackpatch in the API documentation page?

I could ;-)

Post by James Morris
I notice NSM says quite a lot about what applications should and should
not do but there is nothing about ports and auto-connecting. I know
jack session does not allow auto-connect, but some apps provide js with
a unconnected option but there is no way to tell jackpatch of this is
there? Was wondering if jackpatch could detect an
autoconnecting app and disconnect it before it brings up the saved
connections? Or would that cause problems for in certain situations?

Well, that's getting pretty JACK specific. The consensus is that
auto-connection is evil. Jackpatch will not *disconnect* ports under any
circumstances, and it will (uselessly?) remember the connections made by
auto-connecting applications.

Do you have a specific scenario?

James Morris

2012-07-04 01:11:19 UTC

Post by James Morris
I notice NSM says quite a lot about what applications should and
should not do but there is nothing about ports and auto-connecting.
I know jack session does not allow auto-connect, but some apps
provide js with a unconnected option but there is no way to tell
jackpatch of this is there? Was wondering if jackpatch could detect
an autoconnecting app and disconnect it before it brings up the saved
connections? Or would that cause problems for in certain situations?

Well, that's getting pretty JACK specific. The consensus is that
auto-connection is evil. Jackpatch will not *disconnect* ports under
any circumstances, and it will (uselessly?) remember the connections
made by auto-connecting applications.
Do you have a specific scenario?

Only as far as jack clients which autoconnect and are not session
aware go.

I had thought the --unconnected option to be reasonable solution
for jack session but hadn't considered what happens with other session
managers. An --autoconnect option would probably be better instead.

James.

RICHARD WALKER

2012-07-04 01:46:54 UTC

Nothing non-specific here (or should that be NON-specific?) ; I have a
little graphical front-end program written for jack_capture. I use it
to start jack_capture with certain options and in wait mode so I can
connect whatever sources I want to record. I then run the recording
from a jack transport control. All connections are, of course, broken
when jack_capture finishes.

That suited me fine for one-off recording sessions, but then I thought
I would implement a sort of multi-take-session mode. Connections must
still be made manually before running each take, but I expect there to
be anything from minutes to tens of minutes between takes. The gap
might, for example, be filled by re-routing some of the sources,
adding or removing effects ... whatever. But still, to me, manual
connection seemed preferable.

Finally(?) at my brother's insistence, I made an
auto-multi-take-session mode where the expectation is that pauses
between takes could be brief to medium. In this mode I monitor only
those connections to jack_capture (or the meterbridge which it can
start) and I remake them as soon as the new instance of jack_capture
appears for the next take in the multi-take loop. Multiple takes with
a fixed setup can now be simply made just by clicking the jack
transport control. He likes the simplicity of the single click
control.

What I like about NSM and Jackpatch is that it can remember a lot of
confusing looking connections with great ease and in the end I do not
really mind whether some of them were auto-connected by client
applications or not. Yes, this means that with some applications there
will be connections they make which I don't want. In a perfect world I
would remember to configure any offending application so that it will
not auto-connect - if it will let me!

At the moment I am still paddling in the shallow water. I am finding
it quite challenging to get to grips with the computer audio world and
its tools, so I don't mind a bit of patch juggling - it's usually the
least of my problems and among the most obvious to know how to put it
right.

I'm rambling, off to bed now...
Richard

Post by James Morris
I notice NSM says quite a lot about what applications should and
should not do but there is nothing about ports and auto-connecting.
I know jack session does not allow auto-connect, but some apps
provide js with a unconnected option but there is no way to tell
jackpatch of this is there? Was wondering if jackpatch could detect
an autoconnecting app and disconnect it before it brings up the saved
connections? Or would that cause problems for in certain situations?

Well, that's getting pretty JACK specific. The consensus is that
auto-connection is evil. Jackpatch will not *disconnect* ports under
any circumstances, and it will (uselessly?) remember the connections
made by auto-connecting applications.
Do you have a specific scenario?

Only as far as jack clients which autoconnect and are not session
aware go.
I had thought the --unconnected option to be reasonable solution
for jack session but hadn't considered what happens with other session
managers. An --autoconnect option would probably be better instead.
James.

J. Liles

2012-07-04 03:45:57 UTC

On Tue, Jul 3, 2012 at 6:46 PM, RICHARD WALKER <

Post by RICHARD WALKER
Nothing non-specific here (or should that be NON-specific?) ; I have a
little graphical front-end program written for jack_capture. I use it
to start jack_capture with certain options and in wait mode so I can
connect whatever sources I want to record. I then run the recording
from a jack transport control. All connections are, of course, broken
when jack_capture finishes.
That suited me fine for one-off recording sessions, but then I thought
I would implement a sort of multi-take-session mode. Connections must
still be made manually before running each take, but I expect there to
be anything from minutes to tens of minutes between takes. The gap
might, for example, be filled by re-routing some of the sources,
adding or removing effects ... whatever. But still, to me, manual
connection seemed preferable.
Finally(?) at my brother's insistence, I made an
auto-multi-take-session mode where the expectation is that pauses
between takes could be brief to medium. In this mode I monitor only
those connections to jack_capture (or the meterbridge which it can
start) and I remake them as soon as the new instance of jack_capture
appears for the next take in the multi-take loop. Multiple takes with
a fixed setup can now be simply made just by clicking the jack
transport control. He likes the simplicity of the single click
control.
What I like about NSM and Jackpatch is that it can remember a lot of
confusing looking connections with great ease and in the end I do not
really mind whether some of them were auto-connected by client
applications or not. Yes, this means that with some applications there
will be connections they make which I don't want. In a perfect world I
would remember to configure any offending application so that it will
not auto-connect - if it will let me!
At the moment I am still paddling in the shallow water. I am finding
it quite challenging to get to grips with the computer audio world and
its tools, so I don't mind a bit of patch juggling - it's usually the
least of my problems and among the most obvious to know how to put it
right.
I'm rambling, off to bed now...

Have you played with 'takes' in non-daw? Doing multiple takes in non-daw is
a bit easier than what you've described--(although I plan to make it even
easier in the future with one-click looping). At least there's no messing
around with connections. You just click on the 'T' menu button on the track
header and pick 'New'. Then hit home, rec-enable, play. There's no limit to
the number of takes and you can view them all together if necessary. Keep
in mind you can also create a 16 channel track.

James Morris

2012-07-04 10:55:10 UTC

Post by J. Liles
The C interface is file is nonlib/nsm.h in on the 'next' branch in
git. You can just copy it into your distribution. non-daw uses this
interface, most everything else uses the older C++ interface. See the
patch to AZR3-jack
( http://non.tuxfamily.org/nsm/azr3-jack-1.2.3-nsm.patch) as a simpler
example of its use.

I was thrown a little bit by the second call to init_jack in
cb_nsm_open after it's called first in Main::Main.

James.

James Morris

2012-07-04 11:14:32 UTC

I was thrown a little bit by the second call to init_jack in
cb_nsm_open after it's called first in Main::Main.

Sorry I thought it was an error but see now it's to update the jack
name.

J. Liles

2012-07-04 18:50:31 UTC

I was thrown a little bit by the second call to init_jack in
cb_nsm_open after it's called first in Main::Main.

Sorry I thought it was an error but see now it's to update the jack
name.

Yeah. It's best if the client never even registers a JACK client until the
'open' message, but many programs have been written in such a way that that
is difficult to change.

James Morris

2012-07-04 21:40:29 UTC