Hi everyone, can anyone help with this. I bet it's very simple.
I have an index input splitter which is connected to a javascript. The javascript input is also an index.
The input splitter has the index with the value 2, but the input value of the javascript is 1. Can anyone tell me why? It should be 2, right?
In general, input ports only get updated if the patch is executed.
It looks like your JavaScript patch might be attached to a Multiplexer. If the Multiplexer isn't set to receive input from the stream of patches containing your JavaScript patch, the JavaScript patch's input isn't going to update.
Your JavaScript patch is connected to a Render In Image, which is connected to a Multiplexer. If the Multiplexer is set to anything besides input 0, the JavaScript patch will not execute (since it's not connected to any active patches).
That was a mistake. But I've already corrected that. But still, the input value of the javascript changes only between zero and one. And should be: zero, one, or two.
Why go to the extent of using JS for this when an Index value can drive a set of Conditional patches? Works without fail and needn't have any RII patches, which I think will make it more of an efficient composition. [Oh yeah, and just to contradict myself a little, I did use a one RII to provide image feeds through to the Cube faces and the Particle faces].
Actually, you are right that the solution to this is kind of simple. See a verbose and slightly byte heavy way of scripting what you want, still avoids all of those three RII patches though. [still contradicting myself slightly by having one RII to prettify those image inputs].
function (__boolean Start0,
__boolean Start1,
__boolean Start2,
__boolean Stop0,
__boolean Stop1,
__boolean Stop2,
__boolean Reset0,
__boolean Reset1,
__boolean Reset2) main (__index AnimIndex)
{
var result = new Object();
if (AnimIndex == 0) {
result.Start0=true;
result.Start1=false;
result.Start2=false;
result.Stop0=false;
result.Stop1=true;
result.Stop2=true;
result.Reset0=false;
result.Reset1=true;
result.Reset2=true;
}
else
if (AnimIndex == 1) {
result.Start0=false;
result.Start1=true;
result.Start2=false;
result.Stop0=true;
result.Stop1=false;
result.Stop2=true;
result.Reset0=true;
result.Reset1=false;
result.Reset2=true;
}
else
if (AnimIndex == 2) {
result.Start0=false;
result.Start1=false;
result.Start2=true;
result.Stop0=true;
result.Stop1=true;
result.Stop2=false;
result.Reset0=true;
result.Reset1=true;
result.Reset2=false;
}
return result;
}
There are neater ways off doing this but IMHO they tend to lead to learners falling well and truly foul of truthy and falsey distinctions [o = false and 1 = true and so on see http://james.padolsey.com/javascript/truthy-falsey/ for a good article about this and also http://my.opera.com/GreyWyvern/blog/show.dml/1479120]. Anyone want to weigh in with a neater way of making more than two boolean switches please do so.
Whatever, I think that indexes the indices quite well.
Quote: The input splitter has the index with the value 2, but the input value of the javascript is 1. Can anyone tell me why? It should be 2, right?
That's because Booleans can only be true or false, 0 or 1. See the articles linked in my prior post for further details. Thus the verbose script solution required a full set of Start, Stop and Reset outputs for each Stopwatch on each item. Binary - so smart it can seem dumb.
Do you know what, despite all of my earlier remarks regarding RII and arguable efficiencies obtained whereby one uses Macros instead of RIIs there is one thing that macro approach loses for you, namely that wonderful Interactive button on the Viewer window. You won't be able to move those animations around on the screen. Reason being, it's not got a Rendering patch to be interacted with. Just a thought.
In one sense, given the format of your compositional construct, your use of JS was actually quite redundant. See attached picture, reproduce that upon your composition, index.qtz. See what I mean?
Yes, I understand what you say cybero. And thank you for your patience. I've already achieved what I wanted. And you're right. The JS is redundant. Thank you for your help. :)
Well marcofilipevieira, having said the JS is redundant regarding the kind of construct that you used, it would make a lot of sense with other kinds of constructs wherein one maybe wanted or needed to switch on and off more than one animation, possibly at one and the same time, if one jigged the Stop Watch outputs.
In general, input ports only get updated if the patch is executed.
It looks like your JavaScript patch might be attached to a Multiplexer. If the Multiplexer isn't set to receive input from the stream of patches containing your JavaScript patch, the JavaScript patch's input isn't going to update.
The javascript isn't connected to a Multiplexer but a Render in Image. Here's the composition so you can see.
In your first "if" you're assigning 0 to AnimIndex, not testing the value. You must write
not
Your JavaScript patch is connected to a Render In Image, which is connected to a Multiplexer. If the Multiplexer is set to anything besides input 0, the JavaScript patch will not execute (since it's not connected to any active patches).
That was a mistake. But I've already corrected that. But still, the input value of the javascript changes only between zero and one. And should be: zero, one, or two.
hmmm... Ok smokris. I understand what you say. I wanted to stop the animations while another was playing.
By switching upon the Multiplexer, you are automatically turning of the unselected animations.
Why go to the extent of using JS for this when an Index value can drive a set of Conditional patches? Works without fail and needn't have any RII patches, which I think will make it more of an efficient composition. [Oh yeah, and just to contradict myself a little, I did use a one RII to provide image feeds through to the Cube faces and the Particle faces].
http://www.merriam-webster.com/dictionary/indices ...no insult meant, just a small reminder about what the plural form is :-)
Actually, you are right that the solution to this is kind of simple. See a verbose and slightly byte heavy way of scripting what you want, still avoids all of those three RII patches though. [still contradicting myself slightly by having one RII to prettify those image inputs].
There are neater ways off doing this but IMHO they tend to lead to learners falling well and truly foul of truthy and falsey distinctions [o = false and 1 = true and so on see http://james.padolsey.com/javascript/truthy-falsey/ for a good article about this and also http://my.opera.com/GreyWyvern/blog/show.dml/1479120]. Anyone want to weigh in with a neater way of making more than two boolean switches please do so.
Whatever, I think that indexes the indices quite well.
Thank you very much! Really good tips. And those articles helped to understand some JavaScript stuff.
I'm sorry for my bad english. I'm portuguese, not an english native. But thank you for rectifying me. :)
Forgot to mention in regards of
That's because Booleans can only be true or false, 0 or 1. See the articles linked in my prior post for further details. Thus the verbose script solution required a full set of Start, Stop and Reset outputs for each Stopwatch on each item. Binary - so smart it can seem dumb.
Do you know what, despite all of my earlier remarks regarding RII and arguable efficiencies obtained whereby one uses Macros instead of RIIs there is one thing that macro approach loses for you, namely that wonderful Interactive button on the Viewer window. You won't be able to move those animations around on the screen. Reason being, it's not got a Rendering patch to be interacted with. Just a thought.
In one sense, given the format of your compositional construct, your use of JS was actually quite redundant. See attached picture, reproduce that upon your composition, index.qtz. See what I mean?
Yes, I understand what you say cybero. And thank you for your patience. I've already achieved what I wanted. And you're right. The JS is redundant. Thank you for your help. :)
Well marcofilipevieira, having said the JS is redundant regarding the kind of construct that you used, it would make a lot of sense with other kinds of constructs wherein one maybe wanted or needed to switch on and off more than one animation, possibly at one and the same time, if one jigged the Stop Watch outputs.