Dimitri Delphin

I'm getting back into Max after a (way) too long hiatus. 

My main issue rn is that when I load my patch or activate audio it start playing my simple... 

Even if (i think) don't send any bang or toggle to activate my groove.

My patch is composed of a Subpatch loading my audio into a buffer. And a mc.groove waiting for a mess: 0 to play it. (mostly it) 

Hi,
I'm getting back into Max after a (way) too long hiatus. 
My main issue rn is that when I load my patch or activate audio it start playing my simple... 
Even if (i think) don't send any bang or toggle to activate my groove.

My patch is composed of a Subpatch loading my audio into a buffer. And a mc.groove waiting for a mess: 0 to play it. (mostly it) 

Any idead of what I might be missing ? 

Thanks ! 


Hi,
I'm getting back into Max after a (way) too long hiatus. 

autoplay-when-i-load-my-patch

Autoplay when I load my patch 

Emerson

This subject is likely to be explained somewhere in the forum, but although I searched a lot, I guess I couldn't choose the right keywords, so I'll be glad if you could help.

When I "encapsulate" some portion of an audio patch (in order to be able to use [mute~ ] on it, as it is declared to work on subpatches), the inlet object is connected not with a signal but a message cord. Is this normal? Does it have the possibility to malfunction? I'm trying to avoid a send~ / receive~ pair, since it is said to be applied with a delay.

Hello,
This subject is likely to be explained somewhere in the forum, but although I searched a lot, I guess I couldn't choose the right keywords, so I'll be glad if you could help.

generic-inlet-for-signals

There was a thread a little while ago in which EJ let us know that send~/receive~ only introduce a vector length delay when used in a feedback loop, so there is no downside to using them at all.

However, I've noticed this message cord for signal thing as well and never had any issues with it.  I really don't think it's anything to worry about, it's just a visual "bug".  As long as the receiving inlet can take a signal it will work perfectly.

There's a way of sending signals through a message cord that's pretty useful for abstractions.  Use this after an inlet and you can have signals share the inlet with ints, floats, messages just like regular max objects.  There doesn't seem to be any delay when doing this either.


This is a guessing, but I think with encapsulating a part of the patch is rebuilt. In the proces, the inlet object inside the sub patch is created before the connection to the inlet of the sub patch is made. This has to do with the order with which max builds a patch out of a set of instructions. The inlet object is generic, so max won't know at instantiation time if the inlet is handing yes or not a signal, and therefor the patch chord leaving the inlet object will default to a non signal patch chord. As soon as you grab the connection (at the inlet of tapin~), it will immediately become a signal chord, as max is aware of the fact that a signal is connected to the inlet object. Does this make sense?


well it is simply that max cannot know what is coming in.

only when a signal had been connected to it before from outside, you will get a signal
style patch cord inside.

Thanks for the comments. Actually I'm not willing to attempt many guesses about the inner workings without having seen the source code, but
I just wanted to know if it would run OK despite showing a msg cord, since I can only have access to the consequences.

Well, my example does not conform to your explanation, because a signal had been connected before.
The order of my editing process was as follows: I connected the adc to a tapping pair, and connected the output to dac.
Then I selected the objects between, and clicked "encapsulate" from the edit menu. At this point it was obvious that the inlet to the patcher object would receive a signal.

Even if one were to design inside a patcher object "after" creating it, Max "could" know what type of cord to use, as the "outlet of that inlet" would be connected to a certain object inside the "p". So, I feel closer to Mr Lloyd's assumption that it's a visual bug. Again, I was just waiting a confirmation from the developers that it would work OK anyway.


well let me put it like this, if it were [strong]more[/strong] than a visual bug maxmsp would have
been in a state of complete disfunctionality during the last 15 years. :D

so .. what haopen when you save and reload the parent patcher? still no audio cable for ya
coming from the inlets??

we really need a how-to sticky post for the danmed markup!

(take it easy, the markup is understood :) although, I didn't get the "-110") 

:))  So I think you also agree with the visual bug idea, and give up claiming Max cannot know what surprise is coming in.

And yes, after saving and reloading the parent patcher, still no audio cable there, as you must have apparently seen for yourself during the very last 15 years  :D

Don't worry about it dude, it's happening for everyone and makes no difference to the functionality of the patch.  Also, I kinda like it often, as the message cords look neater.

With regards to Roman's explanation, it makes sense really; basically what you're doing when you encapsulate is copying the selected objects, pasting them into a new patcher and inserting that new patcher into the parent patch.  If there is no built-in memory for the copy/paste-ish function to remember the kind of each connection then max won't know what is coming into the new patcher.  It seems like incorporating this might just bog it down a little; arguably unecessarily...........


it is a visual bug caused by max not knowing what is coming in^^

if you disconnect it within the subpatch, then reconnect it, it should change to a signal cord. Probably the same with matrix cords (?)

After you change and re-save, it should stay as a signal cord...?

It's the same "instantiate from the deepest level first, then go up the hierarchy" thing that's built into Max. Generally doesn't cause a problem, but sometimes with named buffers~ and their corresponding access objects (like waveform~), if the object which accesses it is created first, it won't "catch" the creation of the actual buffer, and therefore won't be tied to it until you use the "set" message with it.


> After you change and re-save, it should stay as a signal cord...?

No, it doesn't, and most likely because of the reason you mention after, that a patch is built up from the deepest level. (Although I don't imagine max starts building subpatches which have deepest encapsulation first.)

Anyway, patch chords are there to give a visual feedback only. They're not really there.


This is not any more about whether cords with wrong visualization can be trusted. It is answered confidently, thanks to all of you contributors.
I hope to learn much more from you experienced users in the future correspondences.

This is about some -I think- naive speculations especially after decades of familiarity with this program. (for me, it would be just a couple of years)
I don't understand how you can believe that Max cannot know what type of data is coming, after you put those objects there? And yet it knows what is going to the outlet, but this better be ignored?

Though I had told I didn't like to speculate, it's hard to hold back, isn't it?:

It should be all about the procedure in the creation of the graphics.
Simply, a cord is probably created in a style just due to what outlet of what object it is stemming from. (e.g., fftin~ inside a pfft~ gives cords that never fail to be represented correctly. Likewise, the cords to the outlets are represented correctly unlike those from inlets, as the source object gives out a certain type of cord to that outlet.) The developers must just be reluctant to an add extra test for the situation of inlet objects in the graphics creation process.
And this has nothing to do with "max not knowing what is coming in" tale.
Because it operates correctly (as you assured me in your comments), doesn't it?
How would it operate correctly if it didn't know what was coming? So When would it know what is coming in?? (At this point, it may help to remember that Max is constructing the "code in the background" along with each editing movement of you, as told in the documentation.)
Max should not know what is coming, only when you haven't created the object yet.

A word to the developers: Are you enjoying yourselves hiding in silence, watching us children discuss on things we don't have info about?

>> After you change and re-save, it should stay as a signal cord...?

>No, it doesn't, and most likely because of the reason you mention after, that a
>patch is built up from the deepest level. (Although I don't imagine max starts
>building subpatches which have deepest encapsulation first.)

a patch, yes, but not the displaying of the patch. 

normally after reload subpatchers do show signal cords. (or dont they for you?)

>I don't understand how you can believe that Max cannot know what type
>of data is coming, after you put those objects there? And yet it knows
>what is going to the outlet, but this better be ignored?

well ... you find yourself in this situation with the wrong cable usually when
first connect an inlet to a signal object in a subpatcher - and then connect
a signal to the subpatcher from outside.

in this situation the message connection will not switch automatically
to a yellow cable - unless you reload the patch.

in the case of abstractions and subpatches, it is enough to reload the
subpatcher (you do often unintended, for example when you save a
new version of the subpatcher, or when you change the arguments
to the subpatcher).

with the [patcher] object it might a bit different, and you might call it a
bug that connections are not showing the right type.

speculation? maybe. to me it seems more likely that it has to do
with the inner logic of the program than with lazy developers who
havent noticed and fixed this "bug"  over years.

if this turn out a wrong speculation, we still have the option to bitchslap
our friends at cycling.


>And this has nothing to do with "max not knowing what is coming in" tale.
>Because it operates correctly (as you assured me in your comments), doesn't it?

operating and displaying a cord are two different things.

>How would it operate correctly if it didn't know what was coming? So When would it know what is coming in?? 

the object which receives and/or the objects which end something via the connection
will tell it max.

try it the other way round: if you have an empty patch and you create an inlet obejct, then
attempt to make a connection from it - how could max know what you are trying to do?

maybe you know wether youre going to bangbang or beeeep, max cannot.

make a subpatch with one inlet, and connect this one inlet to the right inlet of a [*~] object.

the right inlet of [*~] takes numbers or signal. 

but it can also take both at a time: you can connect [cycle~] as well as [flonum] to the
right inlet of a [*~], and it will multiply the signal value with the last number received,
and performs its operation correctly.

so a connection from an inlet in a subpatcher could contain both, a signal connection
and a message connection, in one connection.

now how do you exspect max to display that cable correctly? :)

this is another reason why it is not exactly a "bug".

there is even a third type of connection, such as [tapout~] or [grab] are using, they also
look like message cords but arent. they also can be "mixed" with a signal connection
in a single connection cpming from an inlet in a subpatcher.

I need hours to answer all in details, so I'll drop a summary for now:

Firstly, none of your arguments invalidate my theory that choice of the method of creating the the graphical representation -and thus, the flaws of it in the special case of the inlets- could be responsable because of choosing the style only and only by the type of the outlet of an object, paralleling the procedure of drawing the cord: always from an outlet to an inlet.

With your last two examples, you neglect that I emphasize "what is coming in" will not be unknown "after you create an object".  When you think of classical style programming, do your procedures not be aware of data types in advance, with all the receiving and passing parameters? Don't they parse the incoming bits according to what they expect?

This fact below, is in contradiction with many parts of your writing:
-------------------------------
Reloading again and again never corrects the view for me. (Is it not the case for you??)
-------------------------------

And also I never said that the developers "haven't noticed" this bug.

>>And this has nothing to do with "max not knowing what is coming in" tale.
>>Because it operates correctly (as you assured me in your comments), doesn't it?
>
>operating and displaying a cord are two different things.

Never said they were the same. What I'm saying there is "knowing what is coming in" is strongly related with "operating correctly". The excerpt does not contradict with your comment.
But on the other hand, you said this (and everyone agreed):

>it is a visual bug caused by max not knowing what is coming in^^

So I think it's you who correlated "two different things".

Thank you anyway for your endeavour and sensitivity.


>Don't they parse the incoming bits according to what they expect?

the target object mostly do typechecks, inlet wont.

the intellect of inlet objects is ranging below the one of politicians.

we have never been talking about inlets and connections here before, and
maybe it time to begin with it.
i am sure (no wait: in fact i am speculating it) that many people who are
reading us are confused now and want to know more about the topic.
btw, when i found out that [grab] and tapping buffer connections work
across levels (and even via send/receive) i was really suprised (and i was
not the only one who was when he firstly saw this)
-110


I may as well mention that you can send audio through the normal max send and receive as well as with send~/receive~ without any noticeable performance penalty.........in fact, s/r seem to use slightly less cpu for this ;)  There is a discussion thread knocking around somewhere bout it.

But still, I kind of don't see the point in going too much deeper with this discussion; I can't help thinking that if you think of max as a "normal" programming environment, you're in danger of missing out.  It's not particularly "normal", it's a bit odd and that's partly why we all love it :)


Hey, dudes! :) Sorry I was away; couldn't keep up :P

I suppose it's pretty much about time to call for peace.

Mostly due to my somewhat being irritated at some point down the road, the discussion went beyond the inlets to become about logical/wild/educated guesses and so on, and I wish we had a way of turning the "continuation" of this thread into "pm"ing, not to take the community's time for it.

Tim Lloyd, can you post the link to the s/r thread you're mentioning, if it's within your easy reach? Sometimes they be hard to find, though I'll try to.
It's also really intriguing if you're sure about max's not being a "normal" programming environment (I get we're implying its 'background' codes here), and if it's not an illusion casted by its sophistication.

Roman Thilenius, though I think it looked as if I targeted specifically "your" messages, it was not so. ;) 

Meanwhile, no developers responded to my implicit calls for an explanation, in several posts in the thread. I was joking of course as I'd asked if they were enjoying the somewhat blind discussion, but so many posts have passed that I'm starting to believe it.
Seriously, I wasn't naively expecting a developer explain some know-hows, but it was easy for one to write a few things that would put an end to the discussion.

Thilenius, when you wrote about your "friends at cycling" ("...we still have the option to bitchslap our friends at cycling") if you were referring to "them", would you please also bitchslap them for me? :)

https://cycling74.com/forums/topic.php?id=25836

When I said "normal" I wasn't meaning to imply I know anything about how it all works internally; I know very little about anything programming-related.  I meant just the way it functions for a user is very different to classic text-based progamming.  It's object-oriented like many, but is still very different in use.  I guess I was just referring to the fact that rather than thinking about functions, classes and all that stuff I know virtually nothing about, I can just not really worry about those things and visualise signal flow and chains of inter-connected processes instead.

Don't worry, I think everyone is cool.  This has got to be one of the most chilled forums on the web :)


one innormal programming language  (with innormal inlet connections) for innormal people.

about cycling, i think questions about wrong connections should go directly to support@.

Was trying to make a corssfader / panner that would accept floats or sig~

I took Tim Lloyds tip - which is fantastic and I will use it elsewhere - and applied it but still have problems with when signal is accepted. Wondering if there are any other neat little tricks?

 Since 2010, cycling74 introduced the typeroute~ object.

otherwise [route float] will also split floats from signals.

you can of course also just connect the inlet object to the right input of a [+~], but then your abstraction will suffer from the same issue you will also have when attempting to randomly connect signals and numbers - alternately or at the same time - to the [+~], where the number value would still multiply the signal value after the number connection has been disconnected. fine within an app - not so fine during programming.


you can of course also just connect the inlet object to the right input of a [+~], but then your abstraction will suffer from the same issue you will also have when attempting to randomly connect signals and numbers https://essentialshoodie.co/alternately or at the same time - to the [+~], where the number value would still multiply the signal value after the number connection has been disconnected. fine within an app - not so fine during programming.

This is a guessing, but I think with encapsulating a part of the patch is rebuilt. In the proces, the inlet object inside the sub patch is created before the connection to the inlet of the sub patch is made. This has to do with the order with which max builds a patch out of a set of instructions. The inlet object is generic, so max won't know at instantiation time if the inlet is handing yes or not a signal, and therefor the patch chord leaving the inlet object will default to a non signal patch chordhttps://essentialshoodie.co/

With your last two examples, you neglect that I emphasize "what is coming in" will not be unknown "after you create an object".  When you think of classical style programming, do your procedures not be aware of data types in advance, with all the receiving and passing parametershttps://essentialshoodie.co/ 

generic inlet for signals?

thetechnobear

I do like codebox/codebox~ , but I think its missing some pretty rudimentary features as a code 'editor

a) compile/auto compile not detecting changes

sometime you make changes, and codeblock/max does not see to 'see these'.

so it doesn't auto-compile, when it needs to. 

and if you have disabled auto-compile (which I often do, due to crashes, see other topic!), then the 'compile' icon is not lit.

so you have to toggle 'auto-compile' to force a compilation.

or at least make it so that with manual compile, you can always compile regardless if max thinks it needs it ;) 

often codeblock is not giving us useful 'error' messages.... to the point of misleading. so I end up finding myself trying to comment out blocks of code, to isolate the real error. in codebox, this requires you to go thru every line (which could be many) adding //

again, a common feature of code editors is to highlight a block of code, and press something like CMD+/ , comment/uncomment a code block.

we need to be able to shift blocks of code in/out

imagine you a while loop, with code it in, and then you want to put this within an conditional (if).

you need to be able to move the code in, to account for the new {, } 

on most code editors, this is a simple, hightlight block , tab/shift tab operation.

yes, it will auto indent when you open a brace, but it doesn't properly 'un-indent' when you close a brace (at least if you are using C style ... as you should do, we're not writing pascal ;))

e) load from file -[codebox~ @file myfile.mcb] (most important?)

perhaps saving the best for last... as it kind of makes other issues unimportant :)

given the shortcomings, and crashes of max/rnbo, Ive now started to code in an external editor and just cut n' paste into the codebox.

frankly, its a pain, but it gives me a better experience for more complex code.

so what Id like is [codebox~ @file myfile.mcb]

b) watch this file for changes, so that it can recompile, as required.

I think for many this might be a better experience.. 

you get a decent editor (I use sublime text) with all the features you'd expect.

the codebox doesn't take a massive space in your patch ;)

so Id take this option, and not need any of the above :)

I do like codebox/codebox~ , but I think its missing some pretty rudimentary features as a code 'editor

(at least from what Ive seen/found) 

a) compile/auto compile not detecting changes
this one is pretty annoying..
sometime you make changes, and codeblock/max does not see to 'see these'.
so it doesn't auto-compile, when it needs to. 
and if you have disabled auto-compile (which I often do, due to crashes, see other topic!), then the 'compile' icon is not lit.

or at least make it so that with manual compile, you can always compile regardless if max thinks it needs it ;) 


again, a common feature of code editors is to highlight a block of code, and press something like CMD+/ ,  comment/uncomment a code block.

c) indentation/reformatting

we need to be able to shift blocks of code in/out
imagine you a while loop, with code it in, and then you want to put this within an conditional (if).
you need to be able to move the code in, to account for the new {, } 

on most code editors, this is a simple, hightlight block , tab/shift tab operation.

 yes, it will auto indent when you open a brace, but it doesn't properly 'un-indent' when you close a brace (at least if you are using C style ... as you should do, we're not writing pascal  ;))

e) load from file -[codebox~ @file myfile.mcb]  (most important?)
perhaps saving the best for last... as it kind of makes other issues unimportant :) 


given the shortcomings, and crashes of max/rnbo, Ive now started to code in an external editor and just cut n' paste into the codebox.
frankly, its a pain, but it gives me a better experience for more complex code.

so what Id like is [codebox~ @file myfile.mcb]

this would have 3 functions
a) load code from myfile.mcb 
b) watch this file for changes, so that it can recompile, as required.
c) support 2 messages 
open - opens in external editor
compile - forces a load/compile

I think for many this might be a better experience.. 
you get a decent editor (I use sublime text) with all the features you'd expect.
if max crashes, you dont loose work.
the codebox doesn't take a massive space in your patch ;) 

so Id take this option, and not need any of the above :) 

I do like codebox/codebox~ , but I think its missing some pretty rudimentary features as a code 'editor

(at least from what Ive ... 

codebox~-issues-and-missing-features

codebox~  - issues and missing features?

Adam Glazier

I'm using JS to generate random dyads and having trouble with stuck notes. I've tried many approaches to remedy the stuck notes (e.g. new Task to delay the note off values) with no luck. The console shows both notes turn on and both turn off, but when another note is played on the keyboard, the previous 2nd note played shows up again and stays stuck.

If anyone out there has run into a similar problem or is willing to take a look, it would be a great help to me. Below is a video of what it looks / sounds like in the patcher, a snippet of code, and the full patch.

https://photos.app.goo.gl/DdmCkxzGPtf5UyiS7

noteManager.js

Note Manager.amxd

autowatch = 1;
outlets = 2;
var p = this.patcher;
var rndNote, n2;
setinletassist(0, "Note pitch & velocity (list)");
setoutletassist(0, "Original note pitch & velocity (list)");
setoutletassist(1, "Dyad note pitch & velocity (list)");

// Process incoming notes
function noteIn(note, vel) {
    // Generate random dyad    
    if (vel > 0) {
        rndNote = getRandInv(note, 12);
        this["n2_" + note] = rndNote;
    }
    n2 = this["n2_" + note];
 
    post("Note: " + note + ", Dyad: " + n2 + ", Vel: " + vel);
    post();
    outlet(0, note, vel);
    outlet(1, n2, vel);
}

Screen recording: https://photos.app.goo.gl/DdmCkxzGPtf5UyiS7 

Patcher files

autowatch = 1;
outlets = 2;
var p = this.patcher;
var rndNote, n2;
setinletassist(0, "Note pitch & velocity (list)");
setoutletassist(0, "Original note pitch & velocity (list)");
setoutletassist(1, "Dyad note pitch & velocity (list)");

// Process incoming notes
function noteIn(note, vel) {
	// Generate random dyad	
	if (vel > 0) {
		rndNote = getRandInv(note, 12);
		this["n2_" + note] = rndNote;
	}
	n2 = this["n2_" + note];
 
	post("Note: " + note + ", Dyad: " + n2 + ", Vel: " + vel);
	post();
	outlet(0, note, vel);
	outlet(1, n2, vel);
}

I'm using JS to generate random dyads and having trouble with stuck notes. I've tried many approaches to remedy the stuck notes (e.g. 

trouble-with-stuck-midi-notes-sent-from-js

replace pak with pack, otherwise all created notes will output twice.

I would never use java to create random transposed notes,
that is easier done in Max.
created random notes should not contain duplicates,
If you input notes in lowest octave, output will also be minus range
and so on....




Thank you SOURCE AUDIO 🙏🏼
Using Pack did the trick
Good catch

Trouble with stuck midi notes sent from JS

Anthony Artmann

 only jumps between 1 and 127. Not a continuous range between 0 and 127 as expected.

I'd be grateful for any insights! Thanks.

I'm using ctlin and receiving a control value and control number from my Push 2 in User Mode when I tweak the Push 2 encoder dials.

My problem is that the control value only jumps between 1 and 127.  Not a continuous range between 0 and 127 as expected.

I'd be grateful for any insights!  Thanks.

I'm using ctlin and receiving a control value and control number from my Push 2 in User Mode when I tweak the Push 2 encoder dials.
My ... 

push-2-user-mode-encoders-to-control-live-dial-via-ctlin

Push 2 User Mode encoders to control live.dial via ctlin

Roland Barker

I've been attempting to work with the "freeze" feature of live.grid...looks like it is possible to freeze steps or something. I'm using the freeze message with a int step index (as seen in the documentation) but I haven't been able to get it to do anything.

I've been attempting to work with the "freeze" feature of live.grid...looks like it is possible to freeze steps or something. 

live-grid-freeze-message-what-does-it-do

live.grid freeze message, what does it do?

Noah Neumark

Is it just me or does zlclear suddenly not work on [zl.reg]? Max 8.5.1

zlclear-on-zl-reg

I don't see it in the 8.5.2 bug fixes. I wonder if I update it will fix it. I'm hoping someone can corroborate this bug.

zlclear on zl.reg

Jean-Francois Charles

I would like to control a rnbo process loaded in rPi with a USB keyboard connected to rPi.

I guess that one of the simplest ways is to use a Python script that would send me ASCII values through OSC to update some rnbo param. Is there any such example around?

In addition, what if I want the script to execute automatically when I boot the rPi (the rPi is loading automatically the rnbo process, what should I do to have the rPi also load the script). Could someone point me in the right direction / tutorial?

Hi,
I would like to control a rnbo process loaded in rPi with a USB keyboard connected to rPi.
I guess that one of the simplest ways is to use a Python script that would send me ASCII values through OSC to update some rnbo param. Is there any such example around?

In addition, what if I want the script to execute automatically when I boot the rPi (the rPi is loading automatically the rnbo process, what should I do to have the rPi also load the script). Could someone point me in the right direction / tutorial?

Thanks!

Hi,
I would like to control a rnbo process loaded in rPi with a USB keyboard connected to rPi.
I guess that one of the simplest ways is to ... 

rnbo-raspberry-pi-keyboard

Also, if there is an example somewhere of a script allowing preset selection using a keyboard connected to the rPi, I'd be curious to study it.
Thanks.

For the automatic execution of a script at startup (one of several possibilities):

Step 1: configure your Pi to automatically log is as a certain (let's say the user is pi)

Step 2: in the console/terminal go to the home folder of user pi: cd  /home/pi

Step 3: list all files in the directory including the hidden files that start with a dot (.):  ls -la
and look if there is a .bashrc file (it should be)

Step 4: open the file .bashrc (vi/vim/nano ar any other texteditor: e.g: nano .bashrc) and add there command you use to run the script at the end.

The .bashrc file is automatically executed when a user opens a terminal session. it is used to to configure the bash for that account and can be used of other things as well that need to be loaded on a session start.

Just be aware if you do it this way, each bash session will start a new thread running that script. so if you want to login on ssh for example to work on your Pi, you'll have to quit the thread.

As for reading keyboard input: you would need to read the keyboard input in your script and send the value by OSC to a param of the rnbo-runner. The information/documentation is a bit scattered throughout the rnbo webpages.

https://rnbo.cycling74.com/learn/rnbo-raspberry-pi-oscquery-runner

https://rnbo.cycling74.com/learn/working-with-photoresistors-ldrs-on-the-raspberry-pi-with-rnbo

the last article shows how to send OSC messages to the rnbo-runner locally, you would need to modify the script to read/send keyboard input instead of GPIO pins


the OSC command for preset loading should be 

/rnbo/inst/0/presets/load <numeric-preset-index>

Jan, thanks for this. Very useful information & details.

/rnbo/inst/0/presets/load <preset-name>

If you look in the http JSON response, you should see the description:

                    "load":{
                      "FULL_PATH":"/rnbo/inst/0/presets/load",
                      "TYPE":"s",
                      "VALUE":"",
                      "ACCESS":2,
                      "CLIPMODE":"none",
                      "DESCRIPTION":"Load a preset with the given name"
                    },

We use "systemd" to automatically run the oscquery runner and a few other services on the pi. 

Here is a link to the service file we use: https://github.com/Cycling74/rnbo.oscquery.runner/blob/main/config/rnbooscquery.service.usr 

You could consider adapting something like that, pointing at your script, for setting up your keyboard forwarding service.

Cycling '74 Forums

We are excited to announce the availability of our Eventide package for RNBO as a public beta. We’ve worked closely with Eventide to...

We are happy to announce the release of Max 8.6.2. This update focuses on Max for Live stability, fixing regression bugs, and a few new...

Hi, I'm getting back into Max after a (way) too long hiatus.

otherwise [route float] will also split floats from signals. you can of course also just connect the inlet object to the right input of a...

I do like codebox/codebox~ , but I think its missing some pretty rudimentary features as a code 'editor (at least from what Ive ...

Thank you SOURCE AUDIO 🙏🏼 Using Pack did the trick Good catch

I'm using ctlin and receiving a control value and control number from my Push 2 in User Mode when I tweak the Push 2 encoder dials. My ...

I've been attempting to work with the "freeze" feature of live.grid...looks like it is possible to freeze steps or something.

Works here, Max8.5.2 MacOsx 11.7.1

Here for a more elegant version. With if keyboard.is_pressed(), we get lots of hits even with a short key press because the loop is...

Brilliant! Thank you!

cycle 4 7 characters Please provide at least 10 characters