Magic Music Visuals

Yep, that particular change wouldn't affect the playlist duration (for now).

As for shaders or videos, the speed could be linked to the clock such that (for example) it would be faster during a beat, and slower during a non-beat. Which is similar to how this video was created: Or, alternatively, you could use it to loop a video on every beat (by linking the Goto Start parameter to the clock).

Those things probably aren't exactly what you're looking for, but with shaders especially, there's no way for Magic to automatically know what the "period" of the loop is (since shaders never "end"). So it has to be input manually somehow. Which is certainly doable, but just not as quickly as what I mentioned above.

Would you need to phase-lock a higher rate clock to feed to GLSL & video frame rate control?

MIDI clocks have 24 ticks per quarter note, so the temporal resolution is probably sufficient for most purposes. But you might get some jitter, especially at lower BPMs.

Thanks Eric. That sent me thinking further.

Eric wrote:.. speed could be linked to the clock ... it would be faster during a beat...Those things probably aren't exactly what you're looking for...

No, they're not . I have found local speed modulation with music a very useful technique, but it's quite different from what I'm proposing.

Eric wrote:.. but with shaders especially, there's no way for Magic to automatically know what the "period" of the loop is... So it has to be input manually somehow. Which is certainly doable, but just not as quickly as what I mentioned above.

Not what I'm asking for. Naturally, every periodic shader needs to have an individual Speed adjustment to match a particular tempo and desired effect. This is currently part of the scene design, and would remain so.

I'm proposing global speed scaling.
It's a temporal equivalent of the modules' Scale modifier, with global effect in the same manner as the "Adjust Gain" on the audio inputs.

For Video playback & shaders, I believe it's exactly equivalent to a variable DC input on an audio channel that's being used to control speed. It would work now if the audio inputs were DC coupled and one fed in DC proportional to desired BPM.

Suppose one could choose a numerical input (or one of several) as an alternative input in the "audio/MIDI" window.
- The value of the control input would appear as Volume to GLSLShader and Video modules without any changes at module level.
- One change to the numerical value could re-time all the shaders and videos in the project to match a new tempo.
- In the GLSLShader module
-- The desired "BPM-proportional" input would be selected as source.
-- The Volume (ie BPM-proportional DC) feature would be selected to control speed.
-- The scale factor modifier would be adjusted for an integral number of cycles-per-bar for the particular shader.

For oscillator-driven translations I think it would need a modifier that would scale the oscillator frequency with Volume.

I'm proposing global speed scaling.

Ok, I think I get what you're saying now. But you're actually proposing something which is more general than speed. Basically what you want is a "global variable". It's a value you can edit in one place, but which can be used as a source for any number of parameters in any number of modules in any number of scenes. Yes?

Eric wrote:... But you're actually proposing something which is more general than speed. Basically what you want is a "global variable". It's a value you can edit in one place, but which can be used as a source for any number of parameters in any number of modules in any number of scenes. Yes?

In a sense it's a global variable, but I'd like it to control speed in all the following
1) Oscillators
2) GLSL speed inputs
3) Video frame rate for movies
4) Playlist scene duration

I think there are additional requirements if the global control is not to be implemented as a variable system clock as I originally envisaged.

a) For modules that already have a speed control a simple global variable could be sufficient. In effect it's a "DC input to an audio channel" as I have previously outlined and could be selected with the existing Source and Feature listboxes as an alternative* to Volume.
*If one wished to modulate speed with Volume additionally to using the BPM scaling factor, I think the speed would need to be Clamped to the BPM value or the speed would always be "wrong" when the music was playing.

b) For modules that presently have no speed control it needs a means of getting any desired ramp/triangle/sine oscillators to track BPM in proportion to the variable.

c) IMHO The playlist would be greatly enhanced if one could have scenes of eg 4 bars, or a scene used (like a drum fill or syncopation) as a visually percussive transition between others.

Sorry if the above isn't clear. It's 4:15am UK time, and I'm rather tired

a) For modules that already have a speed control a simple global variable could be sufficient. In effect it's a "DC input to an audio channel" as I have previously outlined and could be selected with the existing Source and Feature listboxes as an alternative* to Volume.

Yup, exactly. I envision being able to select "Global Variables" as the source for an Input in the Audio/MIDI window. Then, in any modules, when you select that kind of input as the source, the Feature box will display all the available variables.

*If one wished to modulate speed with Volume additionally to using the BPM scaling factor, I think the speed would need to be Clamped to the BPM value or the speed would always be "wrong" when the music was playing.

I think that's possible, though I'd have to ruminate on it a bit .

b) For modules that presently have no speed control it needs a means of getting any desired ramp/triangle/sine oscillators to track BPM in proportion to the variable.

Presently the Ramp/Sine/Tri modifiers take an input value which affects their speed. So it would be doable when selecting a global variable source.

c) IMHO The playlist would be greatly enhanced if one could have scenes of eg 4 bars, or a scene used (like a drum fill or syncopation) as a visually percussive transition between others.

Ok. I think someone else suggested being able to time the playlist in BPM rather than seconds, which is a good idea.

glad that there is progress on this. eager to see what you are coming up with Eric .

Very exciting!
Global variables! Woop!

Eric wrote:Presently the Ramp/Sine/Tri modifiers take an input value which affects their speed. So it would be doable when selecting a global variable source.

I hadn't realised I could do this already, so I thought I'd play around a bit.
I simulated a global variable by feeding a continuous sine wave into the audio and varying the amplitude. BPM must always be positive, so I think sine wave amplitude (measured by the Volume feature) is a perfect analogue.

Modules were configured to vary Speed, Angle etc as follows
...Source: Input 0 (The continuous sine wave)
...Feature: Volume
........ Scale: (varied for desired effect)
........ Ramp: 0.0

I noticed with the RotateAxis module's angle control, and the Video module's Speed control:
- Negative values for entered for scale were ineffective and the motion stopped altogether instead of reversing direction.
- With the GLSLShader module's Speed, a negative value for scale worked as desired.
I have no problem with these behaviours, although I don't understand the restriction with RotateAxis.

Initial findings: Very promising results, with multiple shaders etc tracking the global speed control
- Could only be sustained for a short time before compromised by drift.
- Very difficult or impossible to exactly match speeds of various shaders, either with each other or with transform modules.
- Problematic not being able to control relative phase of motions within shaders, eg when bounces or direction-reversals occurred.

Conclusion: Means of controlling shaders with the same precision as videos is necessary for syncing.
- Feed a shader with an absolute time value that could be reset to a desired start time on scene change.
- Set an end time/loop point, to match one cycle of movement.
- Ideally a normalising scaling factor would then be computed automatically, needed to map one cycle of shader movement to an desired number of beats/bars.
- Perhaps have an option to cross-fade back to time-zero for looping a shader that does not have a natural or short repeat period.
- Saves having to render a shader's output to a video clip to gain phase control & looping.
- Useful to be able to sync modules directly, feeding a global variable from a particular module's music-responsive parameter.

I noticed with the RotateAxis module's angle control, and the Video module's Speed control:
- Negative values for entered for scale were ineffective and the motion stopped altogether instead of reversing direction.
- With the GLSLShader module's Speed, a negative value for scale worked as desired.
I have no problem with these behaviours, although I don't understand the restriction with RotateAxis.

Videos can't play backwards -- it's just a limitation of how they are decoded. So that's why the Speed param can't be negative in the Video module.

For the Ramp/Sine/Tri modifiers, the incoming value can't be negative either. I think it was just an abitrary decision by me at some point, because you can always add a Scale modifier after a Ramp/Sine/Tri to reverse its direction.

Conclusion: Means of controlling shaders with the same precision as videos is necessary for syncing.
- Feed a shader with an absolute time value that could be reset to a desired start time on scene change.
- Set an end time/loop point, to match one cycle of movement.
- Ideally a normalising scaling factor would then be computed automatically, needed to map one cycle of shader movement to an desired number of beats/bars.
- Perhaps have an option to cross-fade back to time-zero for looping a shader that does not have a natural or short repeat period.
- Saves having to render a shader's output to a video clip to gain phase control & looping.
- Useful to be able to sync modules directly, feeding a global variable from a particular module's music-responsive parameter.

That's some fancy functionality! I never envisioned shaders to be looped and time-scaled in that way (and I'm not aware of anyone else who did either). But it's certainly a unique idea and pretty good one actually .

blackdot wrote:I actually tried out waveclock (the demo) before i stumbeled upon magic. Unfortunately it always crashed on my machine. I sent a mail twice to them, but got no response. So i kept looking and found magic .

for the sake of thoroughness: i tried waveclock again and it's no longer crashing on me. the beat detection works very well as long the music is distinct enough. this will be very useful as my music-counterparts intend to also use vinyl for out next gig which eliminates the traktor-beatclock-to-magic solution. the three additional outputs of wavetick are 'kinda' weird, will stick to magic's magic there, but the beatclock seems solid.

this has nothing to do with syncing the speed of a video to the one of the music (the original topic).

Hi I was just catching up on these threads as BPM syncing was my thoughts for future development. I envisage to have the bpm controls in the audio/midi window. This seems to make the most sense as the bpm is effectively an input. At first, just to have a box where I could write in '140' to set the bpm. Then if parameters could be set to react to divisions of beats.

Personally, I've found tapping tempos to be innacurate except for approximating, which you become more intuitive with after time anyway. But the tap can be useful to get close to the bpm, which you can then type in. Perhaps another way to solve this would be instead of tapping to have a rotatable knob (which would be set to only produce integers), and this could then be linked to a midi knob.

Our current plan is that Magic v1.7 will have some new global functionality, including the ability to set the global BPM by typing in the number directly, as you described. It will also be MIDI-controllable.

And before that, I'm planning on expanding the Beat Clock option into a submenu which has beat divisions, as well as an approximation of the clock's current BPM value.

Dear gentlemans,

GREAT! I just have found the way. Just go with the "speed" parameter to 0, then add a controller number automation to "start time" /f.e. cc 01/. Add a note to "Goto start" /f.e. C-2/. Than make a midi clip in your DAW, draw sixteenth notes C-2 in it and draw the curve of cc 01 from 0 to 127. You can also go with Sine wave on Goto start. It WORKS! It is very funny and it seems Magic has almost no limits, which sometimes remains hidden even for the inventor himself . Anyway, the MIDI SYNC function would be REALLY appreciated, and I really think it is one of the most important functions ever for every musicians who want to come with the videos! This is just a trick which of course don´t work entirely fine, especially on long clips.

Good luck

Petr