live.ppooll dev

[the-steech]

I've just created a new branch for live.ppooll-dev. still probably very buggy, but i wanted to give @klausfilip and @chausch a chance to try and see my changes.

until it's a bit more stable, might be good to keep this separate from main

[klausfilip]

how to test this???
only with live or also backward compatibility?
should the branch work as live-less release as well?

[klausfilip]

your solution with mc-outs as subpatch looks good !!
maybe thats even more convenient for ppooll_in_max anyways.

[klausfilip]

i just downloaded a live trial version.
can you give a brief introduction how to run this with ppooll4live ?

[the-steech]

Yes! You should be able to just drag the .amxd file onto a Live MIDI track. You can route Audio in from other Live tracks. Use INmulti to receive and route that incoming audio

[klausfilip]

amazing !!
so whats the points?

• ll.live.check_envi_type.js checks if its in live and opens acts as bpatchers.
• ll.movewindow is replaced by 11.olsens "move bpatcher" then, right?
• m4l somehow refuses to open the abstraction def_outputs, so we need to nest it in the patcher.
• audio between max and live are maintained by ho_st and INmulti only.
• some more ??
  is there anything, that should not be there in the max-without-live version ?

[the-steech]

Thanks klaus!!! Yes this is all correct.

There are 2 main JavaScript files: ll.live.check_envi_type and ll.live.init_bpatcher.

Check_envi_type happens in an act that loads another act (right now, only ho_st and ll.buffermenu)

Init_bpatcher lives in the "actmaker" abstraction and sets the size of the acts bpatcher.

You're right about audio in via INmulti and audio out via ho_st. The def outputs should appear nested in the INmulti if you hit the open button (may have to click twice, I think it's a bug with my implementation)

The last thing that needs is to somehow load/save envi files with the Ableton Live set. Other than that, it's pretty much done I think!

[klausfilip]

ok !!
just tried to load a simple environment in live and it worked. (with the "old" system though)
anyway, we should try to merge our 2 branches ! (the hassle is ho_st, needs to be done manually i guess)
and then continue from there.
what do you think?

[the-steech]

Maybe best move is to update the live.ppooll branch from main so that I can add your envi changes to live.ppooll version.

Then I can add back the live.ppooll changes to ho_st, etc, then test again.

How does that sound?

[klausfilip]

so you say, i should merge mine to main first?
i would prefer to this tested a bit before.

[the-steech]

ohhh, no i see! in that case, should I? :

• merge my live.ppooll branch into your environment
• add any missing changes from live.ppooll

and then we can test your newly merged environment changes branch from there?

[klausfilip]

yes, i would prefer this.
then we have a branch with all recent updates to test for us...

[the-steech]

if I have your ok @klausfilip, I will make the changes now! just let me know :)

[klausfilip]

please !!
i just backuped my stuff

[the-steech]

@klausfilip all done-- everything seems to be working from my brief testing!! i will be able to test further tomorrow :)

[klausfilip]

fantastic,
first encounter:

• tetris does not change the window size.
• screen ON in an envi should be ignored (or always)

[the-steech]

Not at my computer atm, but there are a couple tweaks that need to be made (making list here to remind myself) - hide host controls: audio on/off, screen, toolbar, # of output channels, etc - set background color according to ppooll prefs

…

On Feb 12, 2023, at 2:25 PM, klausfilip ***@***.***> wrote:  fantastic, first encounter: tetris does not change the window size. screen ON in an envi should be ignored (or always) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[klausfilip]

i worked on ll.mc.def_outputs::
to keep things sorted, there is a new file ll.mc.def_outputsBP
that provides it as bpatcher.
have a look into INmulti ... the def-button is now a toggle to open/close the bpatcher/size window.
can you live with this?

[the-steech]

yes this is working great!!

[the-steech]

@klausfilip when ho_st loads in live.ppooll, i added some "script hide" instructions to the init_bpatcher.js file. here's what it looks like

[klausfilip]

i think its ok to set 16 as default. if somebody sets to less than 16 there should not be a problem. if more i don't know, but i guess it would be just ignored...

[klausfilip]

wher is this init_bpatcher.js sitting?

[the-steech]

ahhh the proper name is "ll.live.initialize_bpatcher.js", in the /javascripts folder

[klausfilip]

i meant, where in the patches is it called/used?

[the-steech]

that .js is called in actmaker abstraction

[the-steech]

made a couple more tweaks. simplified some of the code, removed brackets from param names (this causes issues with dict/json environments), and you can set patcher background from ppooll preferences sub!

[klausfilip]

which params, which brackets? some of them are essential !! like inputs for example..
also param-names of yourse are used in presets and envis.

[the-steech]

i think that conflicts can come up if the actual param name is like"gain[1]", because dicts/json use brackets to find the index of an element in a list. for the live.params_in act, i changed all the params from "param[#]" to "param_#" to avoid this issue. but that was the only change related to this!

[klausfilip]

well, most params[#] are leftovers, created by scripts etc. thats why i ask where you found them.
most likely the pattrs need to be deleted there anyways.

[klausfilip]

[#] also are created if you duplicate a GUI, and then they need a new name.

[the-steech]

yes that makes sense. i think i ran into this issue when i was working on matriarch@. i asked in the max discord, and they advised to avoid using "[#]" in for anything that may appear in a dict/json

[klausfilip]

@chausch the branch "environment speedup" is now merged with the newest hot suff from joe and me.
please give us a go to merge this into main ;)

[chausch]

hi guys, please excuse the silence, i'm super busy atm but will be "back" soon.

just tested the enviroment rewrite. really speedy, great stuff. i could not find any errors from my half hour of testing, but have a small thought regarding the envi-load window being merged into console (which is a good thing imho):
@klausfilip could there be some indicator as to the loading progress? e.g. a counter e.g. 3/12 in front of the act loading message when act 3 from 12 total acts in the enviroment was loaded? or maybe the loading initialization & finalization being split into 2 messages?

reason for this is that i have a ton of old enviroments that do not open correctly anymore (like, really really old ones). before there was the stuck envi load window reminding me of the fact that a certain act was tried to get loaded but couldn't. this way i could identify the culprit, check out the missing (or failing act) and re-import the enviroment.
now there's just the confirmation after the load!

[klausfilip]

unclear to me:
the message
--------environment_loading-----: act modul.ator
is written before loading this act.
if it fails the loading stops there. (and you know there is a problem with the printed act)

if the act loads (responding with its "acting" message) the next act is loaded.

we could add a message after the act loaded - sth like
----done----modul.ator1----
but that would be at the same moment as loading the next act.

[the-steech]

organizational question: do we want to move the .amxd to a separate repo under ppooll organization? might help to keep development of ppooll and the .amxd patch separate

also, i'll start working on install/usage instructions

[klausfilip]

i am not sure. the cute thing is, that its only one .amxd !
and the rest is the same for both - no?
there is no better place than where it is now for my taste.

[the-steech]

@klausfilip really nice work, love all the changes!!! much simpler :) using the .maxpat file for the act's size works brilliantly, we can just do away with all the extra "act_size.json" nonsense

i went ahead and commented out the "live_extras" function. with the control@ changes, we can just remove those extra acts "live.midi_in" and "live.param_in" acts :). i've also remove these files from the repo

additionally, i've created an "info" window with basic rundown of how to use

is it ok if i commit these changes directly to new-createact_js branch?

[klausfilip]

"is it ok if i commit these changes directly to new-createact_js branch?"
oh yes, please ;)

[klausfilip]

actually there is one issue (at least)
that tetris is not loaded with the environment in live.
i'll have a look.

[the-steech]

@klausfilip you should make your changes for tetris, then i'll add my changes and we can merge to main :)

[klausfilip]

done ;)

[the-steech]

@klausfilip I'm also going to remove "act_sizes.json" and related code in tetris@, as well as "ll.live.initialize_bpatcher.js"

[klausfilip]

ok, there was this function name() in tetrishelp.js, that stumbled me..

[the-steech]

it doesn't seem to be in used by anything, at least there is no "name" on the route object above it. going to comment out and test

[klausfilip]

ja, but it can be called by "getpatcher name"

[the-steech]

i can't find that message in actmaker. do you think we should leave it in?

[klausfilip]

obviously it was one of your act_sizes.json hacks,
so delete it.

[the-steech]

all done, should be ready to merge

[klausfilip]

hmm, i did the merge, but something went wrong (again).
main is now behind our branch, but does claim to be the same..
(manually comparing tetrishelp.js)

[the-steech]

it looks ok to me, it looks like the merge was fine and main is the last updated (on my end)

[klausfilip]

if i open tetrishelp.js from main
there is still the function name(name)
maybe its my Github desktop...

[the-steech]

that's weird, it's definitely out of both main and the new-createact_js branch (on my computer) 🤷

[klausfilip]

all good,
recloned and its fine now.
max was opening files from trash
...i will take a break from ppooll_dev now ;)
would like to close this discussion, but no option..,
should we delete it?

[the-steech]

i'm going to lock it, i think we should keep it around while we are still sorta "testing" live.ppooll, it might be helpful as a reference in the future.

thanks for all this, klaus!!!

[klausfilip]

thanks to you my dear !!