matteopennese

It seems the new live objects can't 'survive' without the scripting name. I can delete it but every time I open again the patcher the default scripting name is there again.

Is there a reason for that? I would prefer to be able to delete it; it causes some minor issues in my configuration, e.g. they are always exposed to pattr system.

It seems the new live objects can't 'survive' without the scripting name. I can delete it but every time I open again the patcher the default scripting name is there again.
Is there a reason for that? I would prefer to be able to delete it; it causes some minor issues in my configuration, e.g. they are always exposed to pattr system.

new-live-objects-and-scripting-name

In the Live ui object's inspector, set parameter visibility to 'hidden'.

Maybe I'm missing something, but every time I open again the patcher, the scripting name (a default name) is there and visible to pattr, in spite of the 'hidden' setting.

I'd also just like to exclude live objects from the autopattr system, same problem as matteo. edit: The seemingly unevitable scriptingname also appears in the clientwindow of the pattrstorage object, despite Hidden setting, of course..

maybe I'm missing something too. ?
I'd also just like to exclude live objects from the autopattr system, same problem as matteo. edit: The seemingly unevitable scriptingname also appears in the clientwindow of the pattrstorage object, despite Hidden setting, of course..
cheers
wtg


why don't you just exclude these objects from the pattr system with the second outlet of an autopattr ?

Because i usually do it the other way, which is not a good reason, but this method also seems to introduce more objects and patchcords to patchers which are hard to keep tidy anyways.. But thanks(!) that's kind of a solution.

Because i usually do it the other way, which is not a good reason, but this method also seems to introduce more objects and patchcords to patchers which are hard to keep tidy anyways.. But thanks(!) that's kind of a solution.
Still there should  be a way..?


I'm using the "2th outlet technique", too, even if I prefer the other way...

But I'd like to know if there's a specific reason live.objects must always have a scripting name...

I guess there is a reason with Live's way of working...

loadbang to message "varname" to your Live object

it opens your Live object with a blank scripting name

But I just found this trick :
loadbang to message "varname" to your Live object
it opens your Live object with a blank scripting name


I confirm Live objects are not hidden to pattrstorage when using the 'hidden' parameter (Max 6.0.8).

I confirm Live objects are not hidden to pattrstorage when using the 'hidden' parameter (Max 6.0.8).
Strange behaviour.


i am tying to delete the scripting name of a live.toggle object.

if i set the ‘hidden’ parameter, the scripting name disappear, but if i reload the patch, the scripting name is still there.

perhaps someone from cycling has a hint ?

excluding from the pattrstorage is not an option.

is this bug is still alive ?
i am tying to delete the scripting name of a live.toggle object.

if i set  the ‘hidden’ parameter, the scripting name disappear, but if i reload the patch, the scripting name is still there.

I think the 'hidden' attribute must be seen in the context of M4L as it ensures that the parameter value is not saved with the Live set. But you may not always want to exclude it automatically from pattrstorage which provides a different layer of preset management.

I'm having this problem as well. I was trying to exclude certain M4L numbox and dials from the pattr / autopattr / pattrstorage control, and I thought I achieved this by deleting the Scripting Names. However, default scripting names seem to be auto-regenerated. 

- The only way to exclude M4L numboxes and dials from the pattr system is to connect them to autopattr's second outlet 

- Deleting the Scripting Names of these objects is not an effective way to achieve exclusion of these objects from the pattr system

I'm having this problem as well. I was trying to exclude certain M4L numbox  and dials from the pattr / autopattr / pattrstorage control, and I thought I achieved this by deleting the Scripting Names. However, default scripting names seem to be auto-regenerated.  

Does that indeed mean :
- The only way to exclude M4L numboxes and dials from the pattr system is to connect them to autopattr's second outlet 
   *and*
- Deleting the Scripting Names of these objects is not an effective way to achieve exclusion of these objects from the pattr system

another un-completed aspect of the max and live.object created for another framework but has some advantages over native max object if you stay in max , which mean that user want to use it for max msp project.

We should be able to delete the scripting name or load the object without a scripting name. It's no intuitive that you are able to delete it when you work (so why?), and then when you re open it, a default name is assigned again. We are all aware that live object require a scripting name to be seen in ableton automation.

The go around takes as stated before a loadmess varname, which involved to create unnecessary load objects for such a tiny need.

The go around takes as stated before a loadmess varname, which  involved to create  unnecessary  load objects for such a tiny need.

new live objects and scripting name