My bad... I see what's wrong, just not sure about fixing it.
-George
On Mon, Jul 5, 2010 at 2:48 PM, George Toledo <gtole...@gmail.com> wrote:
> Whoops... sent too early.
>
> This is the composition with the front structure makers redone to be in the
> correct order as well.
>
> It reveals a problem ( I think?).
>
> The final structure coming out of the queue is valid, but when it plugs
> into a mesh creator, I get the structure with nothing but 0's down the line.
> :-/
>
> Is there a reason for this, cwright? I see that the way the structure is
> setup is still different, in that the mesh stuff doesn't enumerate the
> structure with the 1,2,3,4 setup (err, hope my awesome technical
> descriptions make sense).
>
> -George
>
> On Mon, Jul 5, 2010 at 2:42 PM, George Toledo <gtole...@gmail.com> wrote:
>
>> Gotcha.
>>
>> Hmm, I swear I was typing that exact syntax and had it going awry for me.
>> I guess I had a typo going somewhere.
>>
>> On Mon, Jul 5, 2010 at 2:27 PM, Alastair Leith
>> <qc.student...@gmail.com>wrote:
>>
>>> You are declaring an Object not Array, also you are declaring keys not
>>> items. As in dot notation "var.X" not var [*number*].
>>>
>>> See comp for comparison:
>>>
>>>
>>> Also I've included a simple JS patch that unscrambles scrambled
>>> structures. (In some cases at least) There's a note in the comp indicating
>>> the patch I'm referring to.
>>>
>>>
>>>
>>> Best
>>> Alastair
>>>
>>>
>>>
>>> On 06/07/2010, at 4:11 AM, George Toledo wrote:
>>>
>>> Ok, after looking more, I see it was from involving 3rd party patches.
>>>
>>> (I'm still having a heck of a time creating a javascript structure that
>>> keeps it's order though...).
>>>
>>> What do I need to do to make this come back in order:
>>>
>>> var result = new Object();
>>> function (__structure vars) main (__number inputNumber[3])
>>> {
>>> result.vars = new Object();
>>> result.vars.x = inputNumber[0];
>>> result.vars.y = inputNumber[1];
>>> result.vars.z = inputNumber[2];
>>> result.vars.w = 1;
>>> return result;
>>> }
>>>
>>>
>>> The variable names don't matter, I just need them to come back with
>>> inputNumber[0]/x at the "top" and w "at the bottom. Making the Object an
>>> array seems to make no difference. I'm attaching a working/messy file (sort
>>> of), to see what I'm up to. I'm simply trying to make a mouse trail that's a
>>> "box tube", so to speak.
>>>
>>> I understand that where the queue is here is "wrong", but I figure I need
>>> to get the actual order reading correctly anyway. Any help is greatly
>>> appreciated.
>>>
>>> Thanks,
>>> George Toledo
>>>
>>>
>>>
>>>
>>> On Mon, Jul 5, 2010 at 12:50 PM, Christopher Wright <
>>> christopher_wri...@apple.com> wrote:
>>>
>>>> > Is it not possible to make a queue of structures?
>>>> > When I attempt to do this with the queue patch or with javascript, it
>>>> results in an exception.
>>>>
>>>> Trivial applications of this seem to work as expected (generating a
>>>> per-frame new structure using JS, and then queueing the results); can you
>>>> post a sample composition?
>>>>
>>>>
>>> <structure queue test.qtz>_______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com
>>> )
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> http://lists.apple.com/mailman/options/quartzcomposer-dev/qc.student.au%40gmail.com
>>>
>>> This email sent to qc.student...@gmail.com
>>>
>>>
>>>
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
