Channel extent of Vixen 3.0

[chilloutdocdoc]

My $.02 (if only it was actually worth that much)

It'd be a bit of complexity (an extra step/utility) but I'd prefer when show time comes around, My computer is running with the most over-head possible. That is when I'd like to see the byte values tossed around. I have no issue if my adjustable preview is a bit laggy, or skips a few beats because of the sheer complexity of my sequence, but when I run the show that's when the performance is key. Assuming we have these large sequences and effects, we don't want to render everything everytime we want to play (it'd take a while). So why not just render it when you're ready to run your show.

I could imagine it taking tens of seconds for small sequences, or tens of minutes for large, complex sequences. I noticed you were using a lot of Floating Point Operations. Wouldn't it be faster to use a 64bit int or a fixed point operation? Heck, do we really even need 64 bits of resolution? Would 32 hack it? would 16 bits?

Just trying to toss my thoughts in.

[budude]

How about a sequence compiler? Compile the complex "figure it outing" stuff one time and shoot it out to a plain Vixen 2.x like output where it shoots out bytes?

[chilloutdocdoc]

That could be implemented now as an output plugin that wrote the .xml file for Vixen 2.X to play. I was going to do it, but ran out of time. Maybe over summer, or somebody else that wants to do it can do it.

[Zeph]

Additionally, your hardware will make a big difference. Faster CPU and more cores, of course, are going to improve performance.

Which parts of Vixen 3 make use of multiple cores?

I'm looking at faster 2 core vs slower 4 core, where the latter has more aggregate performance IFF one makes good use of all 4 cores. Will some aspects of Vixen (editing, rendering...) do that?

Thanks!

[KC]

Which parts of Vixen 3 make use of multiple cores?

I'm looking at faster 2 core vs slower 4 core, where the latter has more aggregate performance IFF one makes good use of all 4 cores. Will some aspects of Vixen (editing, rendering...) do that?

Thanks!

Most definitely. The updates of the outputs before they're latched to the controllers is done in parallel using multiple threads.

[djulien]

That's been one point of question -- do we do it as additional layers that eventually result in the same thing that 2.x was doing? Since we know that that's the simplest model and provides the greatest performance, it makes sense. But it also means that the data has to get into that state, and since we're no longer generating data in such a simple state, it has to be compiled or rendered down into that state. Now just how and when that's done...

I tend to think that a Vix 3.x to 2.x "compiler" is the simplest approach and leverages the most existing functionality. The controller/prop definitions and nifty effects functions could all be run in Vix 3.x (at whatever speed the host can run at), and just save the generated channel values into a Vix 2.x file. Then use the Vix 2.x playback engine (and all the existing plug-ins as-is) to "execute" it with the correct timing. This would give Vix 3.x instant compatibility with all of our existing displays.

don

[sallz0r]

I tend to think that a Vix 3.x to 2.x "compiler" is the simplest approach and leverages the most existing functionality. The controller/prop definitions and nifty effects functions could all be run in Vix 3.x (at whatever speed the host can run at), and just save the generated channel values into a Vix 2.x file. Then use the Vix 2.x playback engine (and all the existing plug-ins as-is) to "execute" it with the correct timing. This would give Vix 3.x instant compatibility with all of our existing displays.

don

Just to clarify -- with Vixen 3.x, there's *no* going back to 2.x. It's not the same engine, there's no going-backwards-compatibility, etc., etc. We'll have some way to IMPORT 2.x sequences into 3.x, so that you can reuse old sequences and then add to/improve them, but that's about it.

Just wanted to clarify since your post gave the idea of using 2.x for some things -- which isn't the case. Once you start using 3.x, you'll have to stick with it. I know some people are more comfortable with using 2.x -- and there's no problems with that! -- but 3.x is such an overhaul that it's not feasible to make it backwards-compatible in a lot of areas (almost all of them that I can think of).

Edit: What KC was talking about, I believe, was treating some of the concepts in 3.x like the way 2.x execution is handled: dumb execution of byte values. Not actually making it compatible with 2.x.

[KC]

I think maybe Don was thinking about a module that would provide a 2.x-compatible output file.

One of the thoughts early on was about the ability to compile into something that is just played back without any real processing going on, but that was before this latest evolution. It may still be possible, but there may be shortcomings. I guess it depends on how we went about it. Things are always different from the inside once you get in there. But on the surface...you could have an output module that asks for an update frequency that is slow, to make sure it has time to do the conversion, but then writes it out with a different timing...it could also assume the time of each update based on its requested timing...it could fill in some information about plugin configuration based on choices you make for the output module...

...but I'm not good at in-depth thinking on my feet. On the surface, it seems possible, but Michael may see a couple of things that would get in the way that I'm not seeing right now.

[djulien]

I think maybe Don was thinking about a module that would provide a 2.x-compatible output file.

Yes. The advantage to choosing the Vix 2.x format as opposed to another format is that it would give us all the Vix 2.x output plug-ins "for free".

Just wanted to clarify since your post gave the idea of using 2.x for some things -- which isn't the case. Once you start using 3.x, you'll have to stick with it. I know some people are more comfortable with using 2.x -- and there's no problems with that! -- but 3.x is such an overhaul that it's not feasible to make it backwards-compatible in a lot of areas (almost all of them that I can think of).

Edit: What KC was talking about, I believe, was treating some of the concepts in 3.x like the way 2.x execution is handled: dumb execution of byte values. Not actually making it compatible with 2.x.

I realize that Vix 3.x internal data structures and workflow have changed significantly. However, ultimately it still needs to send a stream of bytes out over a wire to the controllers in order to turn the lights on and off. This is also what Vix 2.x does, so it would be fairly easy for Vix 3.x to just write the data to a file in the format that Vix 2.x expects (ie, take "snapshots" of the output data every 25, 50 or 100 msec), and then let Vix 2.x do the actual I/O to the ports. It doesn't have to be Vix 2.x format, but that allows existing plug-ins to be reused.

There would be some advantages to leaving the Vix 2.x playback as a separate, external activity that is completely invisible to Vix 3.x, but it might also be possible to actually wrap the Vix 2.x playback engine as a Vix 3.x "plug in" * and then execute it directly from within Vix 3.x. That would be an interesting integrated approach, but it wouldn't address the heavier processing + RAM requirements so the Vix 2.x playback is probably better left as an external task.

Another way to look at this is to consider Vix 3.x to be a compiler and Vix 2.x to be an assembler, and the byte stream is the machine code. Ultimately they both must generate the machine code byte stream. Some compilers do all the passes themselves and generate machine code directly, while other compilers generate assembler output and then pass that to the assember for final reduction to opcode bytes. Many compilers also provide switches that allow you to capture the assembler or other diagnostic output so you can examine it, modify it, or run it through other tools or alternate assemblers as desired. So, I think we are basically talking about that switch and what it does.

* EDIT: actually, this would be fairly easy - write a Vix 3.x plug-in to collect the byte streams from other Vix 3.x output plug-ins, store them in an internal byte array, and then use a timer to pump segments of that byte array out every 25/50/100/whatever msec to a set of Vix 2.x output plug-ins that have been loaded in memory (and those plug-ins would do the actual port I/O).

/just a suggestion. I don't know how closely this idea aligns with other Vix 3.x goals.

don