My take on that is the only really troubling thing, potentially anyway, is that Lemur uses "frame-driving" instead of separating the GUI from the event thread and using high-precision timers for clocking etc, so object count concerns me more than perhaps programming elegance.
I rely on you guys for the efficient scripting anyway lol! I almost always start building by object-interaction and only later tend to discover some code to replace some or all of the itermediary "mechanicals", as it were.
The formatting, releasing modules in different "scope configs" so people can migrate them through the hierarchy as needed is precisely the sort of thing I meant when I previously referred to this in the Wishlist thread, along with as much documentation as possible (where applicable). So top marks to Macciza for grokking the concept (independently of course, not taking credit).
A few exemplar modules helping folk make the leap from unwieldy inlined (and multiline) "setattribute(blahblahblah etc etc etc)" to declaring variables.
It's great to have amazingly concise, efficient and elegant code . . . I've looked at some very clever stuff from the Library - but much of it remains inscrutable. I can read the code, I can see sort of what it does and even why (sometimes!) . . . but for a novice like myself there's precious little foothold to help get from the basic stuff to even itermediary-level code.
And so I think the Modules section of the forum is going to prove to be the most important - more especially if we can figure out some best-practices.
^^KnobLed_ Module
Re: ^^KnobLed_ Module
Forgot to say:
OI! MACCIZA! GET A MOVE ON WITH THAT MODULE MATE!
No srsly . . . I've been wanting some self-referential code to look at for months now.
The Modules section had been open less than a day and I think I gleaned three missing-links (from my sh*it) in that time!
I do plan to contribute too, when I have something more than rough draft proof-of-concept bits to post.
Cheers guys.
OI! MACCIZA! GET A MOVE ON WITH THAT MODULE MATE!
No srsly . . . I've been wanting some self-referential code to look at for months now.
The Modules section had been open less than a day and I think I gleaned three missing-links (from my sh*it) in that time!
I do plan to contribute too, when I have something more than rough draft proof-of-concept bits to post.Cheers guys.
Re: ^^KnobLed_ Module
Hi
As I mentioned much of it can be factored out into 'library' modules that do most of the work . . .
And the 'load' is really not that much of an impact I don't think . . .
There is probably a lot more being done else where that could be optimised to greater value anyway
What it provides is ease of use for users, particularly novice users, as you don't need to do anything different. Also keeps the internals hidden for those who don't need to see it . . .
This also provides for easier interchange of objects in a project - say swapping from std Knobs to KnobLeds or LEDEncoders with almost no change of existing code . . .
Same thing with some of the other objects - much easier to tell a modified Monitor object LCDMonitor.value= 127; then address lower in the object
There could be multiple layers, hidden objects etc and rather than have to learn the insides of it you just set/get as needed etc...
I guess it is simply a more 'object oriented' approach that I think fits well with the 'modules as objects' idea - they should behave similarly . . .
The other option which may be necessary is to develop some sort of standardish API type approach so there is a common approach to common issues - setting/getting attributes etc . . .
Another issue here is whether to make individual slightly different single-use objects or one highly configurable one with all the bells and whistles . . .
Again this needs a consistent approach across objects to work best in the long run - to avoid having to learn different commands for different objects . . .
As I mentioned much of it can be factored out into 'library' modules that do most of the work . . .
And the 'load' is really not that much of an impact I don't think . . .
There is probably a lot more being done else where that could be optimised to greater value anyway
What it provides is ease of use for users, particularly novice users, as you don't need to do anything different. Also keeps the internals hidden for those who don't need to see it . . .
This also provides for easier interchange of objects in a project - say swapping from std Knobs to KnobLeds or LEDEncoders with almost no change of existing code . . .
Same thing with some of the other objects - much easier to tell a modified Monitor object LCDMonitor.value= 127; then address lower in the object
There could be multiple layers, hidden objects etc and rather than have to learn the insides of it you just set/get as needed etc...
I guess it is simply a more 'object oriented' approach that I think fits well with the 'modules as objects' idea - they should behave similarly . . .
The other option which may be necessary is to develop some sort of standardish API type approach so there is a common approach to common issues - setting/getting attributes etc . . .
Another issue here is whether to make individual slightly different single-use objects or one highly configurable one with all the bells and whistles . . .
Again this needs a consistent approach across objects to work best in the long run - to avoid having to learn different commands for different objects . . .
iMac 2.8G i7 12G 10.6.8/10.7.2, Legacy Dexter/Lemur, Liine Lemur/iPad2, KMI SoftStep, 12Step & QuNeo , B-Controls, Mackie C4 etc
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]
MaxMSP, Live Suite, Native Instrument stuff, etc Modified Virtual Guitar System etc All Projects/Modules © CC-BY-NC-SA[*][/b]
Re: ^^KnobLed_ Module
Cool thead guys!
Agreed , for a consistent object library would be great if modules follows some formating, no saying anything about of changing "our" programming syntax, to me just leaving the variable/s the object is using would be enough. And maybe "Locking" the container to keep it clean for people want not scripting? You can unlock (fortunately it) if you need it.
Also please allows me to say that the use of modules is really "underrated" imho, I personaly love the concept of "modularity" where you work on tons of small modules, and you start creating a big project by inter-conecting them, instead of work in big projects all the time.
Be module my friend
I would wish Liine add a suggestion that analog64 did, to load modules dinamicaly, I just got max to make that, but I would love to have it like an internal function, would be a lovely feature! Please liine add it!
just some thougts.
I can't check this daily, but can upload somethings as soon as I have a bit of free time.
Agreed , for a consistent object library would be great if modules follows some formating, no saying anything about of changing "our" programming syntax, to me just leaving the variable/s the object is using would be enough. And maybe "Locking" the container to keep it clean for people want not scripting? You can unlock (fortunately it) if you need it.
Also please allows me to say that the use of modules is really "underrated" imho, I personaly love the concept of "modularity" where you work on tons of small modules, and you start creating a big project by inter-conecting them, instead of work in big projects all the time.
Be module my friend
I would wish Liine add a suggestion that analog64 did, to load modules dinamicaly, I just got max to make that, but I would love to have it like an internal function, would be a lovely feature! Please liine add it!
just some thougts.
I can't check this daily, but can upload somethings as soon as I have a bit of free time.