Julien Bayle

In my Graal's quest to my visuals & sounds system, I'd need to associate some own data to each objects instantiated in my Java code.

I'm actually instantiating some gridshape inside my Java code.

But I need to add some data (properties related to the sound part of my system for instance)

For instance, I could create classes containing my whole sound related data.

I'd create Java Array (or map or whatever structure) with the data type of those classes.

And then, when I create a visual object, I create also the sound related object and, for instance, the key of the array element is linking both ..

My LOVED way would be to create global objects containing ... ALL I need.

In my Graal's quest to my  visuals & sounds system, I'd need to associate some own data to each objects instantiated in my Java code.

I'm actually instantiating some gridshape inside my Java code.
But I need to add some data (properties related to the sound part of my system for instance)

For instance, I could create classes containing my whole sound related data.
I'd create Java Array (or map or whatever structure) with the data type of those classes.
And then, when I create a visual object, I create also the sound related object and, for instance, the key of the array element is linking both ..

best-way-to-associate-meta-attributes-to-jitter-objects

Not sure why you would not simply wrap a gridshape within a Java class that contains all of the data/functions that you would need. You would then instantiate the gridshape and other needed objects in the constructor, and create functions that would communicate with the gridshape, and others that would perform the additional sound related work you want done.

As this is a fairly general question there may be unforeseen issues, but at first glance don't see why it wouldn't work.

Not sure why you would not simply wrap a gridshape within a Java class that contains all of the data/functions that you would need.  You would then instantiate the gridshape and other needed objects in the constructor, and create functions that would communicate with the gridshape, and others that would perform the additional sound related work you want done.

As this is a fairly general question there may be unforeseen issues, but at first glance don't see why it wouldn't work.


- a core class with global conf + methods to read/write the XML presets (I just read your jdom stuff... :)

- some other classes related to my objects with jitter objects instantiations + bunch of other data

I read the XML preset with the core class.

That one, considering the preset instantiate or not some other classes etc

that way would be very natural for me and easy to extend progressively :)

I'd like to be able to use it like that:
- a core class with global conf + methods to read/write the XML presets (I just read your jdom stuff... :)
- some other classes related to my objects with jitter objects instantiations + bunch of other data

I read the XML preset with the core class.
That one, considering the preset instantiate or not some other classes etc

does it make sense ?
that way would be very natural for me and easy to extend progressively :)


I think the biggest drawback of the Java implementation in Max is that (to my knowledge) it does not allow the coder to declare attributes within the Java environment. This means that you can't expose data to the pattr system, which is a pity. If this did work you would not have to invent your own XML system as it would already exist via pattrstorage.

In your case this may not be the right approach anyway, especially if you are doing conditional instantiation.

I think the biggest drawback of the Java implementation in Max is that (to my knowledge) it does not allow the coder to declare attributes within the Java environment.  This means that you can't expose data to the pattr system, which is a pity.  If this did work you would not have to invent your own XML system as it would already exist via pattrstorage.

In your case this may not be the right approach anyway, especially if you are doing conditional instantiation.


what may not be the right approach? sorry I don't get just that part :p

Sorry - I just meant that if you are wanting to do dynamic instantiation pattrstorage may not be the right way to proceed anyway. You're probably better off creating your own system with XML.

Sorry -  I just meant that if you are wanting to do dynamic instantiation pattrstorage may not be the right way to proceed anyway.  You're probably better off creating your own system with XML.


The idea would only be to read an XML at the startup, modify the preset, write/save the XML at the end.

btw, the concept is the same and require a system.

https://cycling74.com/forums/how-to-save-all-variables-properties-attributes-into-xml-or)

the tricky part will be to be sure to save all :)

BUT ... as you wrote about make my own small classes with all inside (jitter stuff instantiated + my "meta data"), I guess if I store those top level classes, it would save ... ALL.

ok I got it.
I'll probably design my own XML stuff.
It wouldn't take ages I guess.

The idea would only be to read an XML at the startup, modify the preset, write/save the XML at the end.
no more or multiple read after.
btw, the concept is the same and require a system.

in the other thread (https://cycling74.com/forums/how-to-save-all-variables-properties-attributes-into-xml-or) Ross adviced me http://www.castor.org/xml-framework.html
castor framework seems very nice.

the tricky part will be to be sure to save all :)
I mean, i'll have two part:
- pure jitter object
- my own classes.

BUT ... as you wrote about make my own small classes with all inside (jitter stuff instantiated + my "meta data"), I guess if I store those top level classes, it would save ... ALL.


Best way to associate meta-attributes to Jitter objects ???