Run Time Philosophy
m_theater last edited by
if you designed and programmed the patch for a friend, you could put all value into a text file. With the data array actor you can update the values so changes are saved. It is a a bit steep in the beginning but ones you are used to it, it is quite effective.
A tip: in the textfile use the first row as a description header, and let Izzy read out the values from the 2nd row, this way you have a good overview about the different values, even without isadora.
mark last edited by
Is there any mileage at all in my suggestion of making changes to values saveable and changes to actors not? The two things seem very different, but then I am looking at from my own, (selfish), point of
Well, it's mostly a matter of time. Every new implementation requires extensive debugging and testing (not to mention programming.). Somehow, we need to support all that financially if we want the company to stay sustainable. It is for this situation that many people have purchased a USB key edition. They can walk in with the key, tweak, and then walk out. Of course, you're not the one doing the changes I suppose this doesn't really help.
In any case, I've taken what you have to say into consideration. We'll make this a topic of discussion among the team and see if there is a some sort of clever middle ground.
m_theater last edited by
keftaparty last edited by
It's possible to use the data array actor to save / load values when running demo version .
I agree with the idea of "license rental".
No, no new JS features as yet. My thought was in relation to using the data array. It can be difficult getting the data array to do what you would like.
Generally, if I am in a hurry, and I know what are the likely to change parameters, I will load them from an external file, so that other users can make adjustments.
Perhaps not as flexible, but definitely useful for passing projects off to clients.
jhoepffner last edited by
You can modify JS external, using "include" you can edit the code in atom without the need to record the izzy patch.
You can also have your JS actor (or included code) opening a text file containing the settings, you can also record it in the text file.
My apologies for not responding to you sooner - I've been putting a show on.
Thanks for all the suggestions. I have to own up and say that I have tried the Data Array actor method, but with 120 values to save, it all got a bit much. It's been a while since that project, but I also seem to recall that was some weirdness with recalling values from the array on scene activation, (if anyone's interested I'll try and work out what the issue actually was). Thank you to m_theatre and DusX for the text-file suggestions - and it'd never occured to me to edit the file directly, I can't think why not...
I've only ever done the tiniest amount of JS programming: I'll look into it further. Thank you all for the tips on that.
And, as ever, thank you Mark for putting up with my suggestions which can only result in grief for you.
In fact I also was in need of readjusting say projector masking positions because in each theatre projector is not in the same place. Or also you need to calibrate sensors on actor's / dancer's bodies. Frankly I wouldn't bother to buy daily licences. A company that tours and that has a technician who's able to put sensors and that knows how to calibrate them, and has a computer running Izzy to run the show... should simply buy a copy, in my opinion. Running a patch on a demo version (as a runtime) is more likely done in an installation setting than in a live show. For a company that tours. Isadora's cost shouldn't be an obstacle in my opinion.
I agree and I would certainly suggest that a touring company buy a full licence, if they were going to use Isadora more than a bit. But I do think that installations are different. Saying that, the reason I put the word 'Philosophy' in the title was because I'm sure there are different viewpoints, (such as yours), that are equally worthy of discussion.
If you could tweak values and mapping without a license and save changes, then people could theoretically just make versatile template Patches that could handle non-complex shows, tweak them slightly for each show, then save them without ever paying for a license.
I LOVE the idea of daily licenses. When I'm giving private Isadora lessons in person, I usually let the person use my computer and USB Key license, (either in person or via remote access), so that they can save their work. (I feel that being able to walk away from training sessions with a saved patch is a huge help in learning the program.) When I train multiple people simultaneously I can't employ the same method, so I've been contemplating buying myself a number of USB Key licenses to lend out when I'm teaching a group. (Frankly I'm also dying to get more USB Key licenses for multi-computer show-builds, and also so I can edit snippets of a Patch on my laptop while my Mac Pro tower is being used in rehearsal.) I always encourage people to buy USB Key licenses for themselves of course, but I think that allowing people to try out the full version for a daily rate could go a long way towards convincing them to purchase a license for themselves. Daily licenses could be useful for: training sessions ("try before you buy"), touring shows/installation tweaks, and I can also see them being life-savers in "emergency" situations.
If daily licenses existed, I can say with absolute certainty that, regardless of whether I was being paid to train a group or whether I was teaching a friend without charging them, I would always insist that they pay for the daily license. I'm constantly telling people to buy a personal USB Key license, but I'm not always successful in convincing them. However with daily licenses, I could ensure that every time I train someone at least a little bit of money would go to TroikaTronix. So for those of us who teach Isadora without access to multiple licenses, it could be a simple and repeatable way for us to give back to Mark and the TroikaTronix staff for all of their continual support and hard work.
A good point about mapping. I had only been thinking about Actor input and output values - I think that would probably avoid the situation you describe, but I stand to be corrected.