Stretch a routine

[dirknerkle]

Does anybody know how to "stretch" a routine to fit a different time segment? For example, if you save a complicated megatree routine that takes 4 seconds to complete and you want to make it fit into another segment of the same (or different) song but stretch it to 5 or more seconds.

It would be cool to be able to highlight a segment, copy it to the clipboard, select a new segment of pixels over a different period of time, then click stretch and have Vixen do the math and populate the pixels accordingly.

It would also be cool to be able to shrink a segment, too. It's more-or-less the concept of taking an existing set of pixels and making it fit a new time segment.

I'm sure it's a lot simpler to visualize than it would be to code -- after all, a song can only have a consistent time base and this would almost be asking for the time base to be changeable on-the-fly. My guess is that Vixen's very design is predicated on the constant timebase concept which is diametrically opposed to a "stretch" function such as I've described...

Any workarounds out there that might accomplish the same or nearly the same result???

[dj merritt]

I would think that you would have to slow the tempo of the whole song useing a karaoke player with tempo adjust and record the song that way but it would slow the entire song . With my DJ equipment I can slow the tempo without changing the key or even an octive . just a thought dont know if it gives you any other ideas

[prof]

You can manipulate the sample period of the sequence you are copying from. When you copy a range of cells and paste them into another sequence, Vixen only looks at the quantity of cells, not the time period of them. As an example if you copy a 1 second range of cells from a sequence that has a 25ms sample period and then paste this into another sequence that has a 50ms sample period you will find it stretches out to 2 seconds.

It is simple maths to work out the ratio by which you need to change the sample period to get the required change in length.

You can do this entirely from within the sequence you are working on, but repeated re-sampling will have an effect on the smoothness of ramp/fades etc. It would be best to have open a blank sequence that you can copy the required sections into and manipulate them there. Then paste the edited section back in.

Craig.

[dirknerkle]

Thanks everybody. The problem certainly is one of a time base nature. I know Vixen only checks for X number columns/rows of pixels for its copy/paste functions, and I think therein lies the problem: a pixel represents a fixed value over a specific time period and is not related at all to its neighboring pixels. For a stretch/shrink routine to work, the sequences would have to either be based on a much smaller time base than Vixen's "block" method where each pixel represents a fixed number of milliseconds or have an internal reference that "a ramp up starts at point X for Y milliseconds."

Part of the problem is built into Windows and the software development tools themselves -- it's possible to get a much finer time base (microseconds) but when you chop it up into such small segments, it's very difficult to get the program to flow smoothly when you consider the large number of potential channels that must be processed simultaneously. You'd need a Cray supercomputer to create a smooth display!

If Vixen had the ability to subdivide pixels for a certain period of time it could work. Right now, when you change the MS rate for a song, it changes the whole song and affects all fades/ramps/effects instead of only a small segment of time. The ramp up/down/other effects are only functions that calculate values and populate the pixels in a static way -- once the pixels are defined, that's it and there's no reference that they're in a ramp: on playback, Vixen sends the static value of the cell -- whatever it is -- out to the appropriate channel.

Vixen is a well-conceived software program, and it works very well. The more I think about its architecture however, the less feasible implementing a stretch/shrink function becomes. But you have to admit that it was a pretty good idea...

[LabRat]

Perhaps I'm missing somethings, but I don't see how/why the timebase comes into place. Copying from one batch of cells to another disjoint size batch of cells should certainly be possible. (easy for me to say as I'm not coding it, but...)

Consider.. A three cell copy where:

cell 1 = 50%, cell 2 = 10%, and cell 3 = 100%


Paste into a 10 cell location.


cell 1 is set to 50%,
cell 5 (or 6 depending on your rounding method) =10%,
cell 10 is set to 100%
the intermediate cells are then defaulted based on averaging between the two endpoints of each segment. (1,5),(5,10) over the range of intermediate cells.


I think it's akin to "stretch my picture" interpolation. Not always 100% accurate to what you wanted, but I expect it would cover most of the instances desired.

Squishing ? Data gets dropped or more accurately - every "nth" cell gets copied.

Or did I completely miss the point?


Thanks everybody. The problem certainly is one of a time base nature. I know Vixen only checks for X number columns/rows of pixels for its copy/paste functions, and I think therein lies the problem: a pixel represents a fixed value over a specific time period and is not related at all to its neighboring pixels. For a stretch/shrink routine to work, the sequences would have to either be based on a much smaller time base than Vixen's "block" method where each pixel represents a fixed number of milliseconds or have an internal reference that "a ramp up starts at point X for Y milliseconds."

Part of the problem is built into Windows and the software development tools themselves -- it's possible to get a much finer time base (microseconds) but when you chop it up into such small segments, it's very difficult to get the program to flow smoothly when you consider the large number of potential channels that must be processed simultaneously. You'd need a Cray supercomputer to create a smooth display!

If Vixen had the ability to subdivide pixels for a certain period of time it could work. Right now, when you change the MS rate for a song, it changes the whole song and affects all fades/ramps/effects instead of only a small segment of time. The ramp up/down/other effects are only functions that calculate values and populate the pixels in a static way -- once the pixels are defined, that's it and there's no reference that they're in a ramp: on playback, Vixen sends the static value of the cell -- whatever it is -- out to the appropriate channel.

Vixen is a well-conceived software program, and it works very well. The more I think about its architecture however, the less feasible implementing a stretch/shrink function becomes. But you have to admit that it was a pretty good idea...

[dirknerkle]

I wasn't very clear, I guess... Sorry... And yes, the math is pretty simple.

With the example of a simple ramp up from 0 to 100% over 4 seconds where your timebase is 50ms, there are 20 pixes/second x 4 seconds = 80 pixels. When you create them in Vixen, the ramp function assigns each pixel a value, starting at 0 and increasing to 100 at pixel 80.

Using the same 50ms setting, the same ramp up sequence would use 100 pixels instead of the 80. They'd still start at 0% and end at 100% and Vixen would calculate each pixel's value accordingly.

However, once calculated, each pixel has a static value and each pixel stands alone. Vixen reproduces the signal on a pixel-by-pixel basis during play and doesn't know that pixels 209-309 is part of a "ramp up" sequence.

I thought the value of a stretch/shrink routine would be specifically beneficial when using stored routines. A stored routine is essentially a static group of pixels, nothing more, so that when you insert it into another song, it inserts the pixels verbatim. I was thinking of a routine more as a "concept" such as "here's a ramp up routine" and the stretch/shrink routine would dynamically apply the concept of the ramp up over the time (e.g. number of pixels) selected instead of merely inserting the static pixels such as a simple copy/paste operation.

Take a mega-tree swirl for example. Let's say you had a routine that was called "360 degree swirl." The stretch/shrink function would allow you to insert the routine over a 3-second, or 4-second, or 5 or more second stretch of time simply by the following steps:
(1). Highlight the selected pixels over which the swirl was to be inserted
(2). Select the Stretch/Shrink routine function.
(3). Choose the routine to use, which would then be applied to the chosen section of pixels.

Of course, Vixen's ramp functions do the same thing -- I was only using the simple ramp up as an example. A routine could be much more complex than a simple ramp operation. It could include many different elements -- ramps, sparkles, shimmers, etc. -- that are all related to a specific span of time and the stretch/shrink function would simply recalculate where in the NEW time span those functions needed to be performed.

The closest analogy I can come up with is a stretch/skew function for graphics.

[bmcgeeny]

Does anybody know how to "stretch" a routine to fit a different time segment? For example, if you save a complicated megatree routine that takes 4 seconds to complete and you want to make it fit into another segment of the same (or different) song but stretch it to 5 or more seconds.

It would be cool to be able to highlight a segment, copy it to the clipboard, select a new segment of pixels over a different period of time, then click stretch and have Vixen do the math and populate the pixels accordingly.

It would also be cool to be able to shrink a segment, too. It's more-or-less the concept of taking an existing set of pixels and making it fit a new time segment.

I'm sure it's a lot simpler to visualize than it would be to code -- after all, a song can only have a consistent time base and this would almost be asking for the time base to be changeable on-the-fly. My guess is that Vixen's very design is predicated on the constant timebase concept which is diametrically opposed to a "stretch" function such as I've described...

Any workarounds out there that might accomplish the same or nearly the same result???

You can custom set the playback speed so if you take a 4 second sequence and set the playback speed at 80% it will take 5 seconds.

Same amount of cells though.