bpatcher arguments in .module case

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bpatcher arguments in .module case

Théo de la Hogue-2
Hi all,
I would like to warn you about a change that will break nothing ;-)

now in .module patchers it is not needed to put a #1 as argument of the .model patcher and for the .view bpatcher !
(but it is not urgent to remove them as the #1 will simply be ignored).

now the j.model inside .model patcher and the j.view inside the .view bpatcher will automagically read all the arguments written into the top .module patcher (so it will read the name but also any given attribute like @priority, @amenities, ...)

Best,
TO
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bpatcher arguments in .module case

Trond Lossius
Administrator
Thanks Theo,

That’s one of those small “convention over configuration” improvements. Nice!

As I have been making a bunch of views that embed other views lately (I find this a useful way of reusing existing views rather than making new inspectors for stuff), and having reported on and tested for a number of issues, I have a proposal for a workflow regarding naming of views within views that might be more convenient than at current:

90% of the time I either want a view emedded within a view to

a) be named the same as the other view (two examples are the panel in dbap=.view and the larger and editable equalizer view)
b) expose a submodes of the model (some examples are the limiter~.view accessible from the panel in e.g. output~.view and spectral_shift~.view.maxpat. or the hipnoscope~.view that is embedded in amogwai~.view

I very often end up having to add a bunch of objects to ensure that I get the address right. Typically this looks like this (for the (a) case):

<pre><code>
----------begin_max5_patcher----------
345.3ocySssaBCCC84zuhn7bGpsvJW9UlPSgFuQPgjpjTnHD+6qwoUCPnotK
OrGZir8w1Gehy4DBaioEbL5J5KTB4bBgftBNH81D1ddakh6PXLMbzrYGKMFx
Csdzs.dCrJywg.5l8RsB7XR48Nq49psR86uZgJeroSKmjkRyyWDNdFMJJljQ
W2mhTfkuqkOkO6phaZ72Wcm+jBPzC3hf7mpgXyXL55PjKIIgeo+tQt1B0fVP
2aDfZEWHrPWB+r4e1R7X57uR.V9+Z92MoaL.4A3uPAVTNBAHu3wJvzugBj1+
ciRfMioj56eKf7M3+V4wYZrUCkbX2j9ImEfyK0buznuBzxavrUJD.FNaHKoi
uQA37l8v6oQSmhQPm63734STs300G.qqulHU5Va1YrAy4onoTGMwJxrvA4.9
RzC21sM36VEZrw6s1x3ibVXkxpaj3xSRnyWR9.vNTYgB
-----------end_max5_patcher-----------
</code></pre>

or this for the (b)-case:

<pre><code>
----------begin_max5_patcher----------
404.3ocyTkraBCCD8bxWgkk5sTJgzFVt0uiJTkIdnXTvNx1gkh3eu1iSTYSU
.sphCwJyLuY48xDuMNhNQsFLTxHxajnnswQQnKuinF6H5B15hRlAgQkvJ0j4
zjPHKr1ht4vTPWpV0FPVuPHKAKlTZiyJlsXlP9w6ZnvFZZ+zgc5lPx64OeI2
e1y8NYbSJBNVdWKeLKcuhqpsGWcicSIfnawE.Y2TAglQojw9H6hi8GI+NJap
zBocJ4AySyDURkoP4Zzsw+gH+S6M3mDf6L9WogJPxIKTbnbDiy0fKgai+MLO
Mq+IBvTkzZDehTH0KSmnKCo6AUxVDDgW0BV48khMuii3fXI7mnYYY2tjM3Zk
rrqPxRZdNP5vgiVJjGecCRPu+C0SipVWzVxlQl7ME4fwJjLqPI2Ci+Jh8.MS
v4.FuUB3BCaRIfBQ2y9g8RGmiZ04mm+uw4Rllg23zD9zwppVBZSSIwAwszOW
o8l8SPSgLXhUjpgkhV74nGl1sKacKx05vRz57mogTc+Pnk0BbkM124cwek47
IhC
-----------end_max5_patcher-----------
</code></pre>


Would it be possible, when embedding a view within a view, that the embedded view simply inherits the name of the outer view? And if the inner view is passed an argument, then that would be appended to the address, so that e.g. an embedded [limiter~.view limiter] within the view for a /foo model will by default become a /foo/limiter view?

Most of the time, this would be sufficient to connect the views to the correct model, and if I need to do something else, then I could start configuring.

Best,
Trond




> On 09 Sep 2015, at 18:08, Théo de la Hogue <[hidden email]> wrote:
>
> Hi all,
> I would like to warn you about a change that will break nothing ;-)
>
> now in .module patchers it is not needed to put a #1 as argument of the .model patcher and for the .view bpatcher !
> (but it is not urgent to remove them as the #1 will simply be ignored).
>
> now the j.model inside .model patcher and the j.view inside the .view bpatcher will automagically read all the arguments written into the top .module patcher (so it will read the name but also any given attribute like @priority, @amenities, ...)
>
> Best,
> TO
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
tap
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bpatcher arguments in .module case

tap
In reply to this post by Théo de la Hogue-2
hooray!

Tim


On Wed, Sep 9, 2015 at 11:08 AM, Théo de la Hogue <[hidden email]> wrote:
Hi all,
I would like to warn you about a change that will break nothing ;-)

now in .module patchers it is not needed to put a #1 as argument of the .model patcher and for the .view bpatcher !
(but it is not urgent to remove them as the #1 will simply be ignored).

now the j.model inside .model patcher and the j.view inside the .view bpatcher will automagically read all the arguments written into the top .module patcher (so it will read the name but also any given attribute like @priority, @amenities, ...)

Best,
TO
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bpatcher arguments in .module case

Pascal Baltazar-5
In reply to this post by Trond Lossius
Hi !

a) would definitely be nice !

b) I might missing something, but isn’t that already the case ?
Nested views have been working for a long time, when using relative addresses...
if you give‘limiter’ as argument to limiter~.view in input~.view ,
open input~.model.maxhelp
copy the patcher below (just an input~.view in a bpatcher with input~ as argument)
open the inspector (i.e. limiter.view)
doesn’t it work for you ?

<pre><code>
----------begin_max5_patcher----------
325.3occRsraBCCD7ryWQjOmhBBBn1ekppJGmkDCNdircRCBQ+1qeADDpWVI
uyZO6LiujQn03LXn4ej+YNgbIiPBs7MHoyDZOalKYlvXz5Alk2AZZQDjoTnk
YEnJ.qPEbCZR.+LILhZgTXO6gWmPvCGLfMRa4pxBeI+qDnD4mflFMq0v0nT5
GqLgwkB9IamFGa6V1GTrZIz85Eh.SuBT21iMvScPciSWK5fiVIXsmGf3pRo2
WR0XuP4.MKkUvZDp1u0.Ootpcu6021M95lxfXWuuZgbcuTjmmdJQSvNw5ius
6tUqaSQEUnFFs+9XcFzfATwbXA6271+iZVePYomakOvV4RamNn9Itlk4Kg4o
rggIPaRAc3ug6mwQL3X6KBGEJ7gAR0fO8iyWE5vzN+w5VuQcj34caowq5BCs
ZTD7fLOyWy9C+LeoPC
-----------end_max5_patcher-----------
</code></pre>

Cheers !

p


Pascal Baltazar
[hidden email]
http://www.baltazars.org

> Le 9 sept. 2015 à 20:04, Trond Lossius <[hidden email]> a écrit :
>
> Thanks Theo,
>
> That’s one of those small “convention over configuration” improvements. Nice!
>
> As I have been making a bunch of views that embed other views lately (I find this a useful way of reusing existing views rather than making new inspectors for stuff), and having reported on and tested for a number of issues, I have a proposal for a workflow regarding naming of views within views that might be more convenient than at current:
>
> 90% of the time I either want a view emedded within a view to
>
> a) be named the same as the other view (two examples are the panel in dbap=.view and the larger and editable equalizer view)
> b) expose a submodes of the model (some examples are the limiter~.view accessible from the panel in e.g. output~.view and spectral_shift~.view.maxpat. or the hipnoscope~.view that is embedded in amogwai~.view
>
> I very often end up having to add a bunch of objects to ensure that I get the address right. Typically this looks like this (for the (a) case):
>
> <pre><code>
> ----------begin_max5_patcher----------
> 345.3ocySssaBCCC84zuhn7bGpsvJW9UlPSgFuQPgjpjTnHD+6qwoUCPnotK
> OrGZir8w1Gehy4DBaioEbL5J5KTB4bBgftBNH81D1ddakh6PXLMbzrYGKMFx
> Csdzs.dCrJywg.5l8RsB7XR48Nq49psR86uZgJeroSKmjkRyyWDNdFMJJljQ
> W2mhTfkuqkOkO6phaZ72Wcm+jBPzC3hf7mpgXyXL55PjKIIgeo+tQt1B0fVP
> 2aDfZEWHrPWB+r4e1R7X57uR.V9+Z92MoaL.4A3uPAVTNBAHu3wJvzugBj1+
> ciRfMioj56eKf7M3+V4wYZrUCkbX2j9ImEfyK0buznuBzxavrUJD.FNaHKoi
> uQA37l8v6oQSmhQPm63734STs300G.qqulHU5Va1YrAy4onoTGMwJxrvA4.9
> RzC21sM36VEZrw6s1x3ibVXkxpaj3xSRnyWR9.vNTYgB
> -----------end_max5_patcher-----------
> </code></pre>
>
> or this for the (b)-case:
>
> <pre><code>
> ----------begin_max5_patcher----------
> 404.3ocyTkraBCCD8bxWgkk5sTJgzFVt0uiJTkIdnXTvNx1gkh3eu1iSTYSU
> .sphCwJyLuY48xDuMNhNQsFLTxHxajnnswQQnKuinF6H5B15hRlAgQkvJ0j4
> zjPHKr1ht4vTPWpV0FPVuPHKAKlTZiyJlsXlP9w6ZnvFZZ+zgc5lPx64OeI2
> e1y8NYbSJBNVdWKeLKcuhqpsGWcicSIfnawE.Y2TAglQojw9H6hi8GI+NJap
> zBocJ4AySyDURkoP4Zzsw+gH+S6M3mDf6L9WogJPxIKTbnbDiy0fKgai+MLO
> Mq+IBvTkzZDehTH0KSmnKCo6AUxVDDgW0BV48khMuii3fXI7mnYYY2tjM3Zk
> rrqPxRZdNP5vgiVJjGecCRPu+C0SipVWzVxlQl7ME4fwJjLqPI2Ci+Jh8.MS
> v4.FuUB3BCaRIfBQ2y9g8RGmiZ04mm+uw4Rllg23zD9zwppVBZSSIwAwszOW
> o8l8SPSgLXhUjpgkhV74nGl1sKacKx05vRz57mogTc+Pnk0BbkM124cwek47
> IhC
> -----------end_max5_patcher-----------
> </code></pre>
>
>
> Would it be possible, when embedding a view within a view, that the embedded view simply inherits the name of the outer view? And if the inner view is passed an argument, then that would be appended to the address, so that e.g. an embedded [limiter~.view limiter] within the view for a /foo model will by default become a /foo/limiter view?
>
> Most of the time, this would be sufficient to connect the views to the correct model, and if I need to do something else, then I could start configuring.
>
> Best,
> Trond
>
>
>
>
>> On 09 Sep 2015, at 18:08, Théo de la Hogue <[hidden email]> wrote:
>>
>> Hi all,
>> I would like to warn you about a change that will break nothing ;-)
>>
>> now in .module patchers it is not needed to put a #1 as argument of the .model patcher and for the .view bpatcher !
>> (but it is not urgent to remove them as the #1 will simply be ignored).
>>
>> now the j.model inside .model patcher and the j.view inside the .view bpatcher will automagically read all the arguments written into the top .module patcher (so it will read the name but also any given attribute like @priority, @amenities, ...)
>>
>> Best,
>> TO
>> ------------------------------------------------------------------------------
>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>> Get real-time metrics from all of your servers, apps and tools
>> in one place.
>> SourceForge users - Click here to start your Free Trial of Datadog now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
>> _______________________________________________
>> Jamoma-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jamoma-devel
>
>
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Jamoma-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bpatcher arguments in .module case

Théo de la Hogue-2
Hi,
I’ve opened an issue for that and I’ve made a fix for b).
I’m not sure if this is addressing a) as two elements cannot a have the same name into the namespace (unless you mean « address to bind » instead of « name »).

Best,
TO

Le 10 sept. 2015 à 16:32, Pascal Baltazar <[hidden email]> a écrit :

Hi !

a) would definitely be nice !

b) I might missing something, but isn’t that already the case ?
Nested views have been working for a long time, when using relative addresses...
if you give‘limiter’ as argument to limiter~.view in input~.view ,
open input~.model.maxhelp
copy the patcher below (just an input~.view in a bpatcher with input~ as argument)
open the inspector (i.e. limiter.view)
doesn’t it work for you ?

<pre><code>
----------begin_max5_patcher----------
325.3occRsraBCCD7ryWQjOmhBBBn1ekppJGmkDCNdircRCBQ+1qeADDpWVI
uyZO6LiujQn03LXn4ej+YNgbIiPBs7MHoyDZOalKYlvXz5Alk2AZZQDjoTnk
YEnJ.qPEbCZR.+LILhZgTXO6gWmPvCGLfMRa4pxBeI+qDnD4mflFMq0v0nT5
GqLgwkB9IamFGa6V1GTrZIz85Eh.SuBT21iMvScPciSWK5fiVIXsmGf3pRo2
WR0XuP4.MKkUvZDp1u0.Ootpcu6021M95lxfXWuuZgbcuTjmmdJQSvNw5ius
6tUqaSQEUnFFs+9XcFzfATwbXA6271+iZVePYomakOvV4RamNn9Itlk4Kg4o
rggIPaRAc3ug6mwQL3X6KBGEJ7gAR0fO8iyWE5vzN+w5VuQcj34caowq5BCs
ZTD7fLOyWy9C+LeoPC
-----------end_max5_patcher-----------
</code></pre>

Cheers !

p


Pascal Baltazar
[hidden email]
http://www.baltazars.org

Le 9 sept. 2015 à 20:04, Trond Lossius <[hidden email]> a écrit :

Thanks Theo,

That’s one of those small “convention over configuration” improvements. Nice!

As I have been making a bunch of views that embed other views lately (I find this a useful way of reusing existing views rather than making new inspectors for stuff), and having reported on and tested for a number of issues, I have a proposal for a workflow regarding naming of views within views that might be more convenient than at current:

90% of the time I either want a view emedded within a view to

a) be named the same as the other view (two examples are the panel in dbap=.view and the larger and editable equalizer view)
b) expose a submodes of the model (some examples are the limiter~.view accessible from the panel in e.g. output~.view and spectral_shift~.view.maxpat. or the hipnoscope~.view that is embedded in amogwai~.view

I very often end up having to add a bunch of objects to ensure that I get the address right. Typically this looks like this (for the (a) case):

<pre><code>
----------begin_max5_patcher----------
345.3ocySssaBCCC84zuhn7bGpsvJW9UlPSgFuQPgjpjTnHD+6qwoUCPnotK
OrGZir8w1Gehy4DBaioEbL5J5KTB4bBgftBNH81D1ddakh6PXLMbzrYGKMFx
Csdzs.dCrJywg.5l8RsB7XR48Nq49psR86uZgJeroSKmjkRyyWDNdFMJJljQ
W2mhTfkuqkOkO6phaZ72Wcm+jBPzC3hf7mpgXyXL55PjKIIgeo+tQt1B0fVP
2aDfZEWHrPWB+r4e1R7X57uR.V9+Z92MoaL.4A3uPAVTNBAHu3wJvzugBj1+
ciRfMioj56eKf7M3+V4wYZrUCkbX2j9ImEfyK0buznuBzxavrUJD.FNaHKoi
uQA37l8v6oQSmhQPm63734STs300G.qqulHU5Va1YrAy4onoTGMwJxrvA4.9
RzC21sM36VEZrw6s1x3ibVXkxpaj3xSRnyWR9.vNTYgB
-----------end_max5_patcher-----------
</code></pre>

or this for the (b)-case:

<pre><code>
----------begin_max5_patcher----------
404.3ocyTkraBCCD8bxWgkk5sTJgzFVt0uiJTkIdnXTvNx1gkh3eu1iSTYSU
.sphCwJyLuY48xDuMNhNQsFLTxHxajnnswQQnKuinF6H5B15hRlAgQkvJ0j4
zjPHKr1ht4vTPWpV0FPVuPHKAKlTZiyJlsXlP9w6ZnvFZZ+zgc5lPx64OeI2
e1y8NYbSJBNVdWKeLKcuhqpsGWcicSIfnawE.Y2TAglQojw9H6hi8GI+NJap
zBocJ4AySyDURkoP4Zzsw+gH+S6M3mDf6L9WogJPxIKTbnbDiy0fKgai+MLO
Mq+IBvTkzZDehTH0KSmnKCo6AUxVDDgW0BV48khMuii3fXI7mnYYY2tjM3Zk
rrqPxRZdNP5vgiVJjGecCRPu+C0SipVWzVxlQl7ME4fwJjLqPI2Ci+Jh8.MS
v4.FuUB3BCaRIfBQ2y9g8RGmiZ04mm+uw4Rllg23zD9zwppVBZSSIwAwszOW
o8l8SPSgLXhUjpgkhV74nGl1sKacKx05vRz57mogTc+Pnk0BbkM124cwek47
IhC
-----------end_max5_patcher-----------
</code></pre>


Would it be possible, when embedding a view within a view, that the embedded view simply inherits the name of the outer view? And if the inner view is passed an argument, then that would be appended to the address, so that e.g. an embedded [limiter~.view limiter] within the view for a /foo model will by default become a /foo/limiter view?

Most of the time, this would be sufficient to connect the views to the correct model, and if I need to do something else, then I could start configuring.

Best,
Trond




On 09 Sep 2015, at 18:08, Théo de la Hogue <[hidden email]> wrote:

Hi all,
I would like to warn you about a change that will break nothing ;-)

now in .module patchers it is not needed to put a #1 as argument of the .model patcher and for the .view bpatcher !
(but it is not urgent to remove them as the #1 will simply be ignored).

now the j.model inside .model patcher and the j.view inside the .view bpatcher will automagically read all the arguments written into the top .module patcher (so it will read the name but also any given attribute like @priority, @amenities, ...)

Best,
TO
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel


------------------------------------------------------------------------------

_______________________________________________
Jamoma-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jamoma-devel
Loading...