Pangolin quickshow timeline

[Pangolin]

Just edit the "properties" of the event. You can do this by clicking on the green box-looking button, or right-clicking, and then choosing "properties". Then you will be able to tell QS how to animate your cue in lots of different ways. You can choose the frames per second, beats per second, and many other things.

Bill

[flecom]

Hmm... Quickshow hasn't been released for us paupers who splashed out on LD2000 but if it's the same as LD2000 then instead of stretching the event to last 15 seconds, just copy the 3 seconds event then paste it 4 more times so the total event = 3(seconds) x 5 = 15 Seconds.

Or is that too simplistic?

actually in ST2000 you can go to the event properties in the time line and tell it how many times you want to repeat

[soforene]

...... when you import some music into the timeline , do you see a "wave" visuliasation of the peaks and troughs of music? ... as i dont ? yet an image i saw on web showed the waves , right clicking it dont help ..any ideas ..is it something i need to turn on

Just a wild stab in the dark here but is this down to the format of the music file?
In ST2000 the wave visualisation is visible if a WAV file is used but not if an MP3 is used.
Perhaps QS is the same ...........

[Lasermad]

Just a wild stab in the dark here but is this down to the format of the music file?
In ST2000 the wave visualisation is visible if a WAV file is used but not if an MP3 is used.
Perhaps QS is the same ...........

Ahhhh , that sounds like you have hit it on the nail ! shall experiment later

[White-Light]

Just a wild stab in the dark here but is this down to the format of the music file?
In ST2000 the wave visualisation is visible if a WAV file is used but not if an MP3 is used.
Perhaps QS is the same ...........

You also get a waveform with MP3. I've been using them ever since testing started.

[Lasermad]

Bill ,

"Just edit the "properties" of the event. "

As im on a learning curve with this at moment ... heres my thoughts , its just thoughts and suggestions of a someone on the learning curve , not demands , more thoughts of my expectations and suggestions


A) As the abstracts / beams automatically fill the show space you have allocated it , you kind of expect *all* the cues to do the same , when it doesnt work that way it causes confusion , concern and frustration. ( expecially when your on a steep learning curve on a short time )

B) Yes i can now see the "frame repeats" can be used to fill the showspace time allocated with the animation. ( which makes it run at similiar to correct speed) this has solved my issue.

My ongoing concern is the amount of time it takes to do this ,as it doesnt annouce anywhere obvious the actual lentgh of the animation so you can do the maths ... IE .. 3 second animation , 15 seconds of show space = frame repeats 5 ......... so you need to experiment , maybe 3 or 4 times per cue to find the correct speed. Particulary annoying on very short cues.

EXPERIMENTATION TAKES TIME , always in short supply , and it kind of does not seem necessary with some , what appears to be simple adjustments to programming on the face of it .......


If the software said to itself ..........

My master has allocated this cue 15 seconds of "showspace"
this cue is only 3 seconds
I must repeat this cue 5 times to please my master

then my expectations would have been met .......... and i dont beleive that expecation would have been unusual amongst people on the learning curve as in effect some of the cues ( beams/abstracts do it ) automatically and others like animations dont

I beleive this is a suggestion worth passing onto the programmers to improve the functionality and natural progression of building show


PAUL

[White-Light]

Simple way to find cue length, simply pull it onto the timeline and look at the time bar.

I agree there could be easier ways of making it fill the allocated time space eg by pulling it out to fill the time space and having the repeats in whole or part automatically created with the option to turn repeats off via a menu button for those occassions when you want to stretch time. I have a few niggles with the timeline but then again its supposed to be simple with few capabilities. Just watch out for Beyond where I think things may be far more involving.

[Pangolin]

Hi Paul,

We did it the way you suggested in 1.0 and people complained. So we changed it to the way it is right now (which works like ST). And now you are complaining. I guess there is no way to stop everyone on earth from complaining...

My second point is, are you a programmer? If so maybe you'd like to come to work for us and show us how it's done .

Bill

[Lasermad]

Hi Bill

"We did it the way you suggested in 1.0 and people complained"
Just shows you cant please all of the people all of the time
Please do be careful to not confuse suggestions/ideas with complaints.

Maybe thats why it felt so frustrating , as it had worked the way i expected in the past and you moved the goalposts without telling me . I was trying banging my head trying to get a functionality thats been removed.

Currently trying to think of a reason why someone would not want the cue to simply "work" without intervention at filling the time you allocated it , but possibly more of a case of additional functionality required , that involved turning off the easy way of doing things.

"are you a programmer?"
Yes im outstanding at basic on a ZX81 , but a few years since i pulled out the tape recorder

"If so maybe you'd like to come to work for us and show us how it's done"
You have already done it , so you got that one covered


Anyways show has been done , shown to the 600 kids who screamed when the lasers turned on and quickshow overall made it easy !

paul

[norty303]

To be fair to Pangolin, they've actually done it the hard way and allowed timestretching to be the default behaviour. (anyone who remembers Logic/Cubase pre-timestretching will know what I'm talking about )

I guess there is no way to stop everyone on earth from complaining...

Perhaps there is... perhaps you could use a modifyer key (CTRL?) so that it timestretches by default, or repeats if the modifyer is held.

Given that Bill has said it has worked both ways in the past, perhaps it wouldn't be too hard to implement, as the code likely exists already to do it both ways.

But again, how much of this neat stuff is going to devalue the 'Pro' products...



Incidentally, as a programmer (of sorts) myself, I found this to be a particularly pertinent document to remind me daily of what is important:

Ten Commandments for Egoless Programming:

1. Understand and accept that you will make mistakes.

The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code.

Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
3. No matter how much "karate" you know, someone else will always know more.

Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
4. Don't rewrite code without consultation.

There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience.
Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
6. The only constant in the world is change.

Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position.

Knowledge engenders authority, and authority engenders respect -- so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat.

Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
9. Don't be "the guy in the room."

Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Critique code instead of people

Be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.