Sine/Tri Phase Offset

[artnik]

Would it be possible to add a phase offset from 0-1 on the oscillators? 0 would be no offset, and 1 would be a full cycle offset.

I ran into issues when trying to use Sine Osc to create an animated wave of several polygons, each using a Delay to offset each polygon's point in the cycle of the sine wave. The issues were that using a time delay meant that only one possible Sine increment value would work (full cycle in 1 second), and that until the delays caught up to each one the bars were stationary. I think this would greatly expand the creative possibilities of these modifiers.

P.S. Kudos on a brilliant piece of software. I have been waiting years for something like Magic.

[artnik]

I'm posting a .magic file to illustrate the issue. When it starts, or when you re-sync, you can see that each bar has to wait for the delay to kick in. With an offset, it would animate correctly from frame 1. I think this is a good example of a similar "delay" issue raised in this post: viewtopic.php?f=4&t=562

Sine_Bar_Wave.magic

Using delay to offset a Sine Oscillator across multiple objects.

(2.66 KiB) Downloaded 1467 times

[Sadler]

Very clever - I like it - even the delay

[Magic]

Would it be possible to add a phase offset from 0-1 on the oscillators? 0 would be no offset, and 1 would be a full cycle offset.

It's a good idea, and I definitely understand what you are saying. The issue is that, currently, modifiers can only have one parameter. The Sine Osc's parameter is used to control its oscillation speed, so I'm not sure where I'd put a separate phase offset parameter. I'll have to think about it a bit... but feel free to let me know if you have any ideas.

[artnik]

Would it make sense to have a separate modifier called "Phase Offset"? So if it was in the stack it would be applied to any oscillator below it in the stack? That way if you added any additional OSC modifiers down the road it would also apply.

[Magic]

That wouldn't work unfortunately, at least with the way things are currently designed. Each modifier receives its input from whatever directly precedes it, and in the case of the Sine Oscillator, the input is used to adjust the oscillation speed. Check out viewtopic.php?f=3&t=274 for a somewhat in-depth description of this.

It would certainly be possible for me to create another version of the Sine Oscillator which uses its input to adjust phase instead of oscillation speed. I'll spend some time thinking about how I could do it in the way that would make the most sense.

[artnik]

Interesting. I didn't realize you could pass values to the oscillators, and had assumed that the TRI and SIN were simply dictated by their parameter value.

In that case, is it correct to assume that having a version of SIN and TRI to which you pass just an offset would still let you control the speed of the cycle by using a RAMP or INCREASE/WRAP to drive it? If so, that would totally work for any case I can think of.

Thanks Eric!

[Magic]

In that case, is it correct to assume that having a version of SIN and TRI to which you pass just an offset would still let you control the speed of the cycle by using a RAMP or INCREASE/WRAP to drive it?

Yup, that's mostly correct . The parameter would control the phase offset, and the input would still control/affect the speed, but the input wouldn't necessarily need to be a Ramp or Increase; it could just be a constant value to create a steady oscillation.

Having a Ramp or Increase as the input would cause the oscillation to accelerate over time, which may or may not be the effect a user would want.

[artnik]

That makes sense. Thanks.

[Terry Payman]

With Eric's latest beta release 1.65b, there's an incredibly powerful Expression modifier. You can get your rate-independent phase offset easily using the sin(x) function by adding a phase offset to x.

I was playing around getting a feel for the possibilities. Here's a crude re-work of your elegant wave project as proof of principle. The Translate modules differ in the offset to a ramp, which then feeds a sin() function. I got the phase and scaling wrong and the modifiers are hugely over-complicated, but it works!

I'm sure you can fix it faster than I can, so I'm passing the baton!

I mentioned the idea to Eric, and

If you feed an Increase modifier into the Expression modifier, you can just do sin(x + [phase offset]).

[Magic]

Thanks Terry. Probably the easiest chain of modifiers would be:
- Ramp (with whatever speed you want)
- Expression: sin((x+offset) * 2pi), where offset is just a constant value between 0 and 1 that you increment slightly for each subsequent module.

Quick example provided below.

SineOffset.png (80.29 KiB) Viewed 19893 times

A few notes:
- The Expression modifier understands pi and several other constants, so you don't have to specify their value.
- As a shortcut for multiplication, you can say 2pi instead of 2*pi.
- In the first Translate module, I am really saying sin((x+0) * 2pi), but this simplifies to sin(x * 2pi).
- If I had four polygons instead of two, the offsets would be 0, .25, .5, and .75. Or if I had 10, they would be 0, .1, .2, ... .9. Etc.

[Terry Payman]

Clean and simple. Thanks Eric.

I found it a little tricky to edit in the small Expression box, and definitely easier to have an independent offset modifier that held just the phase, preceding a sin() Expression which remains unchanged for all the different phase instances.

Also, I found some longer expressions became partially obscured once editing was completed, so reverted to redundant modifiers to keep everything clearly visible. On balance I prefer the ease of maintenance of a separate offset modifier.

[Magic]

You're right, that's an important consideration. Having a separate Offset modifier would allow the expression to remain unchanged, and I can definitely see how it would be easier for some users to manage it that way. In this case there's no real advantage to either method, because modifiers take only a miniscule amount of processing power.

I knew there was going to be an issue with long expressions; unfortunately I couldn't come up with a good way to make the text box bigger but still have it fit in the existing module design. I will certainly think about it more for future versions. In the end I decided to show the expression in the tooltip (as in the screenshot above), so at least it could be seen all at once.

[artnik]

Does it have to be "Expression"? Can you save some space by making it a label like: Ex, Exp, Fn, Fnc, Func?
I can see the logic in aligning all the variable input fields, but the graphic designer in me wonders if that's strictly necessary given the amount of unused space.

I've quickly mocked up what wider boxes might look like. Assuming that all field names can be shortened to a 6-7 character limit (the drop down to add them already contains full names with shortened labels after choosing so that's already a convention). The right-justified labels for modifiers will maintain an indent compared to the left-justified source labels (A) and given that all modifier elements are already visually separated by the different background, it helps to group the modifiers visually (B) to the source they are affecting. This way you're almost doubling the space.

In maintaining the strict alignment of all input boxes, you actually create a strong margin that visually groups elements between parameters, and across the fields' container boundaries. At a glance it can create more confusion that way as to what belongs with what.

Reclaiming that unused space in the interface may come in handy for future use as well.

2¢.

Margin Change.png (47.15 KiB) Viewed 19881 times

[Magic]

Haha, cool It always means a lot to me when people take the time to submit in-depth suggestions like that.

I definitely agree that there is unused space on the left side of the modifiers. The only thing I don't like about making the input boxes bigger is it implies (to me at least) that the text should fill the box. However, it almost never will because Magic only measures numerical values to 4 decimal places (i.e., 1.9999).

For example, it drives me nuts when I'm on a web site entering my credit card, and it asks for my 3- or 4-digit security code in a box that's wide enough to fit 20 or 30 characters. It happened to me yesterday on the site for a movie theater:

UnnecessarilyLargeTextBox.png (12.68 KiB) Viewed 19871 times

The reason I don't like it is it makes me feel like I'm doing something wrong by not filling up the box. In my opinion, from a UI design perspective, input boxes should be sized reasonably to fit what they will contain. I don't want users to feel like they are doing something wrong when a modifier or parameter box says only "1.0" and there's a bunch of whitespace left over.

I thought about making the box bigger for the Expression modifier only, but then things wouldn't look nice and aligned. More importantly though, expressions can be very long, so the box will never be big enough to fit every possibility anyway.

What do you think about this: having the Expression box temporarily expand to fit the entire expression while the text is being edited, but then collapse again when it's done? If you wanted to see the whole thing again later, you could just click into the box.

[artnik]

...and I love it when people respond in fashion.

LOL That was an extreme example, but I get your reasoning.

An expanding box sounds like a great way to deal with it.

[Terry Payman]

+1.
Perfect.