Best way to associate meta-attributes to Jitter objects ???
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)
What is the best way to do that ?
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 ..
sounds ugly, I mean: not cute.
My LOVED way would be to create global objects containing … ALL I need.
Any leads/clues ?
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.
Thanks a lot Jesse.
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 :)
Yes, that certainly makes sense to me.
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.
no it’s me and my frenchie english :)
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.
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.