PDA

View Full Version : 3.0 Beta 0



Pages : [1] 2

KC
11-26-2011, 07:42 PM
Happy Thanksgiving to everyone! I hope there was some good food and great company for everyone.

We think we've got something that's stable enough for the hardy of heart to play with. My apologies for not hitting our September goal. While we could have put something out that month, there have been a lot of changes since then that we would have dragged you guys through, and that doesn't seem fair. The changes have died down and it's been calm for a while now, so the time is right.

What to Expect

Very basic functionality. The intention of this is to garner feedback. Please, please do not use this for your display. We like it when you guys stay up and running and aren't brought down by our hand. You will be able to administer your setup and create and execute sequences. We've been playing with it for a while, but we know how it's supposed to be used, so it behaves quite well for us. It may be that a normal person lays their hands on it and it bursts into flames because of what we didn't anticipate, and that's what we need to know.

What's Included (so far)


Administration application - setting up your controllers, channels, groups, creating and opening sequences.
Module testbed application - so you can write a module and test basic functionality. Supports the most common modules types.
Editor - just a single editor for now for simple timed sequences.
Effects - five basic effects.
Media - basic audio support.
Hardware - just Renard right now, but more is coming. We can only develop against what we personally own. But there is also a "dummy lighting" module that gives you visual feedback on Renard output. This is NOT a preview, just visual output feedback.
Preview - Erik Mathisen has been putting in a lot of work on a better preview. It's not 100% where he wants it yet, but he would appreciate your feedback on it. There are only circles to draw with currently, but we had to start somewhere. Play with it, get a feel for the direction he's going in.
RGB Property - Apply this to RGB channels and groups and effects that are aware of it can handle those groups more intelligently. This particular property works with single-channel RGB and RGB that is made up of separate red, green, and blue data channels.


I feel like I'm cutting you guys loose without enough information. There is so much more that could be said and explained, but I'm trying to be brief for a change (too late!) and not make this an unreadable post. Just what Michael's done with the editor alone could be a separate post. However, there are a few things you should know to be able to use it:

1. Administration is pretty key. You define your display once and then write sequences for that single display. As it was mentioned in an earlier post, three things you will need to set up are:

- Channels and groups (logical channels of your display elements, e.g. "Front door")
- Controllers (if you have a 24-output Renard controller, you create a 24-output Renard controller)
- Patching between the channels and controllers ("I want the 'Front door' data to go to the first output on my Renard controller)

Some of this can be done for you. When you define a controller, there is a button for generating the channels for you, if you wish. We would have liked to add more such functionality, but it was a slippery slope and we had to put a stop to it at a point.

2. In the editor, you drag effects onto the work surface and then edit them (by moving, resizing, or double-clicking to setup the effect). This is very different from existing versions. Once you drag on an effect, you can drag it around to change the timing of it or the channels it will be applied to.

3. Try to avoid extremely high channel counts for now. It will result in huge editor startup times.

Also, read back through the 3.0 introduction posts. They have some good foundational information.

What you see is pretty utilitarian in some cases. That will change over time; we don't intend to keep it like that. There are more modules to be added, but we didn't feel they were quite ready. Also, there are going to be sample module projects posted so you can get an idea of how to author one. Each one has a basic walkthrough, but they do assume you have some basic Visual Studio knowledge. ctmal has put together a series of videos that are much more comprehensive and cover the basics more thoroughly, including preparing your development environment. I don't know if he's posted them yet, so if he hasn't, I'm guessing he will soon now. :)

We know you have choices out there and we prefer that you use what works for you and keeps you up and running. If that happens to be us, awesome, we appreciate it. If not, well...the point of all of this is to help you create a show that you enjoy putting on, regardless of how you get there. We do this because we love doing it and you should have the same experience as well.

Thanks for reading. I'm going to go grab some Thanksgiving leftovers.

- K.C. and the Vixen team

P.S. I guess you need a link! Here: Vixen 3.0 Beta 0 (http://www.vixenlights.com/files/Vixen 3.0 Beta 0.zip).

P.P.S. And a link to...the aforementioned samples (http://www.vixenlights.com/files/Sample Modules.zip).

Jakeleg1969
11-26-2011, 07:56 PM
Thanks KC. Your efforts and time are sincerely appreciated. This Beta software will give me something to play around with durng the "off" season. Merry Christmas...

Jerry in Louisiana

lightman
11-26-2011, 08:13 PM
Sounds great KC... I will give it a try and let the team know any feedback. Thanks to all your team for updating the package. I know it is hard work...

Lightman

Mactayl
11-26-2011, 08:22 PM
Will try it in the morning, thanks for all your hard work along with any other folks involved with this.

abrianbaker
11-26-2011, 08:38 PM
Very Excited!!!!! And THANK YOU and the team for a job well done on all versions of Vixen. It is much appreciated!!!!!!

Aurbo99
11-26-2011, 08:41 PM
I could kiss you K.C!! lol

KC
11-26-2011, 08:58 PM
I could kiss you K.C!! lol

lol, and here I am without a single bit of mistletoe.

Aurbo99
11-26-2011, 09:00 PM
WOW.. A whole new interface. Gonna take a bit to get used to all the new wiggets and giggets..

Only 15minutes in and I already have a test sequence built.

Messing with the Available effects..

Coach
11-26-2011, 09:07 PM
Cool,

I just completed my first two Renard ss24 boards and can begin learning how to program them on the newest Vixen. I plan to be ready next year so I will be growing my skills at the same time you are refining your software.

Thanks, Harry

Livermore-Dad
11-26-2011, 09:08 PM
whooohoooooooooooo and if someone got a test seq up and running in 15 minutes, that's better than I did with my failed attempts at trying LSP!!

Tory

Macrosill
11-26-2011, 10:40 PM
OK. First a huge Thanks goes out to KC and the team. Now onto the real stuff, LOL.
I guess I will be the 1st. If there is a bug tracker or other reporting method let me know, otherwise:

Value cannot be null.
Parameter name: PortName.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ArgumentNullException: Value cannot be null.
Parameter name: PortName
at System.IO.Ports.SerialPort.set_PortName(String value)
at System.IO.Ports.SerialPort..ctor(String portName, Int32 baudRate, Parity parity, Int32 dataBits, StopBits stopBits)
at CommonElements.SerialPortConfig..ctor(SerialPort serialPort, Boolean allowPortEdit, Boolean allowBaudEdit, Boolean allowParityEdit, Boolean allowDataEdit, Boolean allowStopEdit)
at VixenModules.Output.Renard.Module.Setup()
at Vixen.Sys.OutputController.Setup()
at System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.239 (RTMGDR.030319-2300)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
VixenApplication
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/VixenApplication.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.235 built by: RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.236 built by: RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
Vixen
Assembly Version: 3.0.0.0
Win32 Version: 3.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Vixen.DLL
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233 built by: RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
Microsoft.CSharp
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.CSharp/v4.0_4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.dll
----------------------------------------
System.Xml.Linq
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml.Linq/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233 built by: RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Dynamic
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Dynamic/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Dynamic.dll
----------------------------------------
Anonymously Hosted DynamicMethods Assembly
Assembly Version: 0.0.0.0
Win32 Version: 4.0.30319.239 (RTMGDR.030319-2300)
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dll
----------------------------------------
System.Runtime.Serialization
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 (RTMRel.030319-0100)
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Serialization/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll
----------------------------------------
DimmingCurve
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Transform/DimmingCurve.DLL
----------------------------------------
Curves
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/App/Curves.DLL
----------------------------------------
ColorGradients
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/App/ColorGradients.DLL
----------------------------------------
CommonElements
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Common/CommonElements.DLL
----------------------------------------
DisplayPreview
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/App/DisplayPreview.DLL
----------------------------------------
PresentationFramework
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/PresentationFramework/v4.0_4.0.0.0__31bf3856ad364e35/PresentationFramework.dll
----------------------------------------
WindowsBase
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233 built by: RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/WindowsBase/v4.0_4.0.0.0__31bf3856ad364e35/WindowsBase.dll
----------------------------------------
PresentationCore
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.233 built by: RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_64/PresentationCore/v4.0_4.0.0.0__31bf3856ad364e35/PresentationCore.dll
----------------------------------------
System.Xaml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Xaml/v4.0_4.0.0.0__b77a5c561934e089/System.Xaml.dll
----------------------------------------
Generic
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Timing/Generic.DLL
----------------------------------------
Audio
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Media/Audio.DLL
----------------------------------------
Chase
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Effect/Chase.DLL
----------------------------------------
Pulse
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Effect/Pulse.DLL
----------------------------------------
SetLevel
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Effect/SetLevel.DLL
----------------------------------------
Spin
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Effect/Spin.DLL
----------------------------------------
Twinkle
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Effect/Twinkle.DLL
----------------------------------------
TimedSequenceEditor
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Editor/TimedSequenceEditor.DLL
----------------------------------------
ChaseEffectEditor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/EffectEditor/ChaseEffectEditor.DLL
----------------------------------------
ColorGradientTypeEditor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/EffectEditor/ColorGradientTypeEditor.DLL
----------------------------------------
ColorTypeEditor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/EffectEditor/ColorTypeEditor.DLL
----------------------------------------
CurveTypeEditor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/EffectEditor/CurveTypeEditor.DLL
----------------------------------------
LevelTypeEditor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/EffectEditor/LevelTypeEditor.DLL
----------------------------------------
SpinEffectEditor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/EffectEditor/SpinEffectEditor.DLL
----------------------------------------
TwinkleEffectEditor
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/EffectEditor/TwinkleEffectEditor.DLL
----------------------------------------
DummyLighting
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Output/DummyLighting.DLL
----------------------------------------
Renard
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Output/Renard.DLL
----------------------------------------
Timed
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Sequence/Timed.DLL
----------------------------------------
RGB
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Users/Brian/Desktop/Vixen%203.0%20Beta%200/Vixen%203.0%20Beta%200/Modules/Property/RGB.DLL
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 (RTMRel.030319-0100)
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
5v0lh1gm
Assembly Version: 1.0.0.0
Win32 Version: 4.0.30319.236 built by: RTMGDR
CodeBase: file:///C:/windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

budude
11-26-2011, 10:44 PM
Is there an E1.31 plug-in available for 3.0 - if not then it's a non-starter for me unfortunately...

Greg in Canby
11-26-2011, 10:48 PM
Thank you KC and team!! I'm away from my computer for a couple of days but can't wait to try it out.

KC
11-26-2011, 10:58 PM
OK. First a huge Thanks goes out to KC and the team. Now onto the real stuff, LOL.
I guess I will be the 1st. If there is a bug tracker or other reporting method let me know, otherwise:

Value cannot be null.
Parameter name: PortName.

Possibly you have no serial ports? If so, I admit that this oversight is my doing.


Is there an E1.31 plug-in available for 3.0 - if not then it's a non-starter for me unfortunately...
Not currently, but it's one of the ones being worked on.

foxathome
11-26-2011, 11:10 PM
From download to something I created displaying onscreen was 20 to 30 minutes. This included the system autodetecting the need for and launching a link to Microsoft .NET 4.0 download and completing the .NET install. Restart the executable and the application was running!
I've generated a random sequence and had it display in the dummy lighting display.
Not sure how to do anything productive in it yet, trying to wrap my head around the new editor.

Thanks for the new Beta, appreciate all of the work that goes into this.

KC
11-26-2011, 11:37 PM
This included the system autodetecting the need for and launching a link to Microsoft .NET 4.0 download and completing the .NET install.
Confound it, I forgot to mention that! Thank you...yes, it's built against .NET 4.0.

Also looking into exposing our bug tracker for beta bugs. I did update the zip file with what should be a fix for the no-port issue.

sallz0r
11-26-2011, 11:46 PM
Just to add to what KC has said -- I plan on writing up big walkthroughs and tutorials on things, maybe even a few screengrab videos on how it all works -- but unfortunately I'm simply flat-chat at the moment (with my own display), so won't be able to write up something for a few weeks at least. So for the time being, you'll have to fly a bit blind and just experiment to see how stuff works. (That can be a bit of a good thing, though; you'll probably be able to find the bugs a lot quicker than we will if you're experimenting. ;-) )

However, if you have specific questions about things, feel free to ask! I'll try and make as much time available to answer specific questions or problems as they come up.

Jakeleg1969
11-26-2011, 11:52 PM
However, if you have specific questions about things, feel free to ask! I'll try and make as much time available to answer specific questions or problems as they come up.

This kind of attitude is what I like about this group...

Thanks

Jerry in Louisiana

Coach
11-27-2011, 12:00 AM
Real quick niggle.

If I make a link to the executable on my desktop and then try to launch from there I get an error, if I go to the folder and launch from there it works fine. Seems to be a pathing thing.

Best regards, -Harry

Macrosill
11-27-2011, 12:05 AM
Possibly you have no serial ports?
...

What is a serial port?







Correct, this machine has no serial port.

KC
11-27-2011, 12:10 AM
What is a serial port?
We used them back in my younger days. We'd take a rock and slam it on a wire repeatedly; called it "bit-banging". Then they came up with this fancy "electricity" idea...

Materdaddy
11-27-2011, 12:12 AM
Thank you for all the hard work KC and team! From the two minutes I've played with it, it seems like this will make many things easier, especially when dealing w/ large amounts of channels, RGB, etc.

What is going to be the correct venue for reporting bugs? I have a feeling forum posts will get out of hand with "how do you reproduce this?" mixed in with additional bugs, and chaos will ensue.

I have already found a couple bugs. Maybe one of the first changes would be to have the alert window for backtraces put the text in a textbox which can be copy/pasted for bug reports.

Coach
11-27-2011, 12:18 AM
Please disregard, Stupid end user trick. Made a copy of the exe rather then a link to it.

-H



Real quick niggle.

If I make a link to the executable on my desktop and then try to launch from there I get an error, if I go to the folder and launch from there it works fine. Seems to be a pathing thing.

Best regards, -Harry

KC
11-27-2011, 12:22 AM
What is going to be the correct venue for reporting bugs? I have a feeling forum posts will get out of hand with "how do you reproduce this?" mixed in with additional bugs, and chaos will ensue.
We're in the process of exploring a couple possibilities. With some luck, we'll have a winning solution tonight.

Edit: DynamoBen, who has been acting as our bug tracker admin, is going to give it all a good think and get the administration sorted out. He'll post in this thread when it's good to go.

Materdaddy
11-27-2011, 12:57 AM
We're in the process of exploring a couple possibilities. With some luck, we'll have a winning solution tonight.

Edit: DynamoBen, who has been acting as our bug tracker admin, is going to give it all a good think and get the administration sorted out. He'll post in this thread when it's good to go.

Cool beans. I figure I'll keep anything I see to myself until there's a better venue for reporting things with steps to reproduce, versions, information, etc. Thanks KC!

Matt_Edwards
11-27-2011, 06:43 AM
KC & the Team,
Thank You. Sure looks promising. Hopefully you will get the DMX output plug in next so i can play some more.

Once again team thank you. You guys rock.
Matt

lbro
11-27-2011, 10:37 AM
KC,
I downloaded and started playing. Once again you are the best! Another great leap forward!

your friend LEO :-)

KC
11-27-2011, 12:25 PM
your friend LEO :-)
Lou! Great to see you're still around! I was talking to someone about the Philly mini a couple years back and mentioned the huge spread you brought. I'm sorry, but I called you Leo before I realized what I had said. It's like my brain thinks it knows what your name should have been.

tronman
11-27-2011, 03:45 PM
I loaded up .Net 4.0 and got the exe to go.
I too was able to load a short wav file and dummy out some effects to the dummy light display.
I dont have the controller listed ( I have a Hill controller).
What is a node and what is rendering?

Thanks for all your hard work.
Bob G

smartalec
11-27-2011, 04:11 PM
looks like a nice challenge to start playing with,
do you know much about the progress of the E1.31 driver?? my usb dongle dont work too well

KC
11-27-2011, 05:37 PM
What is a node and what is rendering?
Good questions. Ideally, you wouldn't be exposed to those terms unless you're looking to develop a module. Where are you seeing them?

To answer the questions, a "node" is something that represents either a channel or a group. So if you're looking at something being called a node and it's not a channel you've created, it's a group of channels (or a group of groups).

"Rendering" is what we're calling the process that creates the data being output from the effects that you're working with.

erm213
11-27-2011, 06:05 PM
looks like a nice challenge to start playing with,
do you know much about the progress of the E1.31 driver?? my usb dongle dont work too well

I am working on getting the E1.31 and the DMXUSBPro (Entec Pro compatible) modules working. I hope to have them done within the next few days.

Erik

Matt_Edwards
11-27-2011, 06:47 PM
I am working on getting the E1.31 and the DMXUSBPro (Entec Pro compatible) modules working. I hope to have them done within the next few days.

Erik
Erik, you are real Rip Snorter Bonza Mate.
Thanks
Matthew

DynamoBen
11-27-2011, 09:25 PM
We're in the process of exploring a couple possibilities. With some luck, we'll have a winning solution tonight.

Edit: DynamoBen, who has been acting as our bug tracker admin, is going to give it all a good think and get the administration sorted out. He'll post in this thread when it's good to go.

I spent today working on this. It is taking a more time than I had hoped largely because I want to make sure things are working then we only have to do it once. I will post details once things are sorted, thanks for the patience.

plasmata
11-27-2011, 09:51 PM
Downloading now....

Thanks KC and the Sunshine Band for all your hard work!

plasmata
11-27-2011, 10:44 PM
OK, first minor issue. I added a Renard controller then increased the channels to 24 and clicked update. That worked fine. I then renamed it to Renard SS24 and it updated fine. Then I added another Renard, changed the channels to 64 and renamed it Renard 64XC. Then I clicked generate channels, OK, and opened Configure Channels and Groups. I saw the 64XC channels but wanted the SS24 listed first. So I deleted All the channels, went back to Configure Output Controllers, highlighted the SS24 and generated the channels, then did the same for the 64XC. All showed up in the Channels & Groups but the SS24 channels were not named properly. They were listed as Renard-1, Renard-2, etc. They should've been Renard SS24-1, Renard SS24-2, etc. For whatever reason the 64XC channels were listed correctly. Again, not a huge issue, I just renamed each channel individually but a bug nonetheless. From what I understand the intention is to name the channels after the display element (mega tree1, etc.) anyway.

I also managed to crash the app by deleting all the channels a second time, went back into Configure Controllers, chose the SS24 and clicked update again to try to get the "new name" to take again. However I hadn't actually changed anything. It crashed when I clicked OK to close the Configure Controllers window. I'm not sure I could recreate this but I somehow managed to do it. Go figure.

plasmata
11-28-2011, 12:13 AM
OMG! You guys must be geniuses. Either that or I am. :wink: So I'm a total newb when it comes to sequencing. Never touched the stuff. I just did a chase sequence on an 8 channel mega tree to the opening of TSO's Christmas Canon and within minutes had the timing spot on! I even changed the speed of the chase at the end and it looked great. Now I know this is only a small piece of the song and only one display element but I can tell that the time saving will be enormous. The great part is that I could expand the MegaTree to 12 channels with very little effort to update the sequence. Thanks again for the great work and can't wait until additional modules are available.

A couple of convenience items I'd like to see. Could you have the option to turn on time markings at the bottom of the sequence editor? I also would like to be able to drag and drop channels to change the order. If that's not possible then maybe click on a channel and an up or down arrow to move it. Oh, one more thing, I would like to be able to add channels to an existing group. This would be helpful for my MegaTree example where I want to change it from 8 channels to 12. If that would be too difficult then the next best thing would be to add a new MegaTree group and be able to drag and drop the effects from the 8 channel group to the 12 channel. Time alignment would have to be maintained while dragging it.

sallz0r
11-28-2011, 12:19 AM
A couple of convenience items I'd like to see. Could you have the option to turn on time markings at the bottom of the sequence editor? I also would like to be able to drag and drop channels to change the order. If that's not possible then maybe click on a channel and an up or down arrow to move it.

You can click-drag to rearrange channels/groups in the channel editor configuration window; that order is the one that's used for sequences. So you can rearrange stuff that way.

plasmata
11-28-2011, 12:28 AM
Didn't notice that. I was trying to do it in the sequence editor. I just tried it your way and it works great. Thanks sallz0r! Oh, and I also found out that I could drag and drop the effects from an 8 channel group to a 12 channel group and the effects adjusted on the fly. Awesome work!

sallz0r
11-28-2011, 12:42 AM
Didn't notice that. I was trying to do it in the sequence editor. I just tried it your way and it works great. Thanks sallzor!

I was originally thinking of adding the ability to have different 'orders', like 2.x, but realized that it's just extra complexity that's not really needed; the only reason 2.x really needed them was because everything was flat, and generically named, so it was impossible to easily keep track of what's what.

However, with 3.x, you can group them to help organize things, and close groups you don't need. And, if you want to manipulate the data in different ways, just make another group with the nodes ordered differently! (ie. you can have a group "minitrees-all", which is all of them, then another group "minitrees-odd" which is only the odd-numbered trees, or something like that.). I've done one with my display -- I've got "icicles-side" which is all on the side of the house, "icicles-front" which is all on the front, and "icicles-all" which is all of them. So I can just apply an effect to whichever group I want! :-)

plasmata
11-28-2011, 12:56 AM
I'd like to see the preview editor make use of the channel groups and have built in elements that you could associate them to. So that my 12 channel group could be linked to a megatree element and I could then drag that conical representation on the display layout. I could also see a need for properties on this object. By default I would expect to see channel 1 be located in the front. But it would be nice if I could choose a different channel as the front and have the element rotate accordingly. This is just one property I could think of but there's probably more that other users would want. Some additional elements I would expect to see are arches, circles, vertical and horizontal lines, windows and candy canes. These are just user friendly ideas. Whether or not you could actually code something like this I have no clue.

sallz0r
11-28-2011, 01:04 AM
I'd like to see the preview editor make use of the channel groups and have built in elements that you could associate them to.

Yeah, that's ultimately where we're going (I think -- I'm probably speaking out of turn, as the preview is Erik's module!) -- but that's a bit more work. There's still heaps to go, but that's what this 'initial feedback' stage is. :-)

deplanche
11-28-2011, 01:23 AM
In the sequencing window, I've noticed that the stop shortcut is listed as being CTRL-S, which is also used for saving and sort of confusing.

tdpolo26
11-28-2011, 01:56 AM
In the sequencing window, I've noticed that the stop shortcut is listed as being CTRL-S, which is also used for saving and sort of confusing.

hey sorry to hijack..and was wondering if you were running renard. i am just looking for someone who has a working board to compare to mine. i am having a bunch of issues and could use the help if you know renard

tronman
11-28-2011, 08:51 AM
KC,
In response to your question,
In the Channel and Group Configurations window on the right, in the 'operations' frame is where nodes are added and deleted.

If I understand what you're saying; a channel is a string of light(s), a group is a collection of selected channels, and a node can be a collection of groups and/or individual channels, and a node can be in a group?
So by making these configurations the program 'renders' the necessary code to generate the proper output?

zaker
11-28-2011, 09:10 AM
KC and dev team, Great work!

plasmata
11-28-2011, 09:52 AM
KC,
In response to your question,
In the Channel and Group Configurations window on the right, in the 'operations' frame is where nodes are added and deleted.

If I understand what you're saying; a channel is a string of light(s), a group is a collection of selected channels, and a node can be a collection of groups and/or individual channels, and a node can be in a group?
So by making these configurations the program 'renders' the necessary code to generate the proper output?

My understanding of a node is that it is just a generic term to refer to a channel or a group. The reason for introducing this term is to make it easier for the coders. Rather than labeling a field as "Channel or Group" they simply use "Node". So on that screen, you could be adding, deleting, or modifying a channel or a group (i.e. a node) depending on which type you choose. A channel is a light or string of lights, a collection of channels is a group, and a collection of groups is also a group. But all of these can be referred to as a node, without specifying which of the three you mean.

Your statement that a node can be in a group is correct in that either of the two types of nodes (channel or group) can be added to a group. The term "node" also leaves the option for future node types to be added without the coders having to change all of the screens where they apply.

I hope this helps rather than adds further confusion.

rrowan
11-28-2011, 10:35 AM
Is the vixenlights.com site down?

I tried the link and I get go daddy ads only

Thanks

Rick

g2ktcf
11-28-2011, 11:40 AM
something is up as I am trying to email KC and all of my emails are being rejected.....

Materdaddy
11-28-2011, 11:47 AM
Is the vixenlights.com site down?

I tried the link and I get go daddy ads only

Thanks

Rick

Looks like somebody forgot to renew the domain name!

EDIT: Upon further looking, it doesn't expire until 2013... maybe godaddy hosting/dns got confused?

a158946
11-28-2011, 11:52 AM
<offTopic>
another reason not to use godaddy besides their horrible ads. I'd rather pay a little extra for a company that doesn't need sex to sell their services.
</offTopic>

DynamoBen
11-28-2011, 03:54 PM
Is the vixenlights.com site down?

I tried the link and I get go daddy ads only


We are making changes to the site, this might have been an inadvertent consequence of those changes. Checking into it now.

akonkman
11-28-2011, 04:09 PM
KC & the team,

You guys are definitely taking Vixen in the right direction in my mind. I've occasionally toyed with the idea of creating my own sequencing software that kept the simplicity of Vixen 2.x but added features such as RGB, grouped channels, etc. I'm using some RGB strings this year and made the decision to go with LSP to handle the high channel count sequencing that I was looking for. I went through quite a bit of pain learning LSP this year (definitely not what I would call "simple"... and at times a bit "quirky"). LSP's transition feature (where it takes an AVI file and translates it into RGB node effects) saved me quite a bit of time, but all the while I was thinking "man, if only Vixen had some of these features...". Well, now that I've played with Vixen 3.0 beta for just 10 minutes, I'm already jumping for joy inside. This 3.0 platform (and yes, I believe this is more than just a software package... it is truly a platform now) has the potential to be an absolute game changer! Features such as the AVI-file-to-channel-effects would now be possible by simply creating a new effect module. Genius! And the ability to apply effects to groups of channels is one of those "jeez, it just makes so much sense now that I've seen it... I don't know how we could ever have lived without it" features. I can't want to start sequencing and building on this platform in the coming year! Look out 2012!

Thanks, KC and team, for all you've done on this. As a software developer myself (.NET, by the way... I'm looking forward to playing around with module development and sharing with the community when the time comes), I can appreciate elegant design when I see it... and I'm definitely seeing it with Vixen 3.0.

KC
11-28-2011, 06:54 PM
Sorry about the site problems, guys. I started playing around with the domain while at work, got interrupted too many times, and am working on straightening out the mess right now. Should be looking better in a couple hours.

Macrosill
11-28-2011, 07:49 PM
I had nothing to do with it this time, LOL.

sallz0r
11-28-2011, 08:29 PM
In the sequencing window, I've noticed that the stop shortcut is listed as being CTRL-S, which is also used for saving and sort of confusing.

Ha, nice catch. Yeah, I think they were added separately, thanks for pointing that out. :-)

sallz0r
11-28-2011, 08:36 PM
My understanding of a node is that it is just a generic term to refer to a channel or a group.

<snip>

Yep, got it in one. Thanks for the explanation.

The intent would be, for most normal operation, for people to have channels that are simply 1:1 patches with outputs on your controllers. That's what happens when you hit the 'generate channels' button on your controller config. Then, you could group those channels into meaningful groups. For example, you have 16 channels that map to 16 outputs for your megatree, so you might call the channels "MegaTree-1" through "MegaTree-16", then you could group those into a single group called "MegaTree". This way, you can apply effects to it, and it can figure stuff out much more easily.

And as you said, all of these things -- channels or groups -- are nodes, simply as a more generic term to make referring to them easier in dialogs, buttons, etc.

rrowan
11-29-2011, 11:07 AM
Hi KC

Thank you for getting the site back up. I got the files and will check it out as soon as I get my show going for this year. Been very busy working on that and very tired at the moment

Thanks again

Rick

g8rfn
11-29-2011, 11:14 PM
Hi guys. Perhaps I am doing something wrong... but when I try to test the effects i can only expand them side to side to make the duration longer or shorter. I cannot seem to figure out how to select multiple rows to apply an effect to, or expand the effect from a single row to multiple rows?

erm213
11-29-2011, 11:17 PM
Hi guys. Perhaps I am doing something wrong... but when I try to test the effects i can only expand them side to side to make the duration longer or shorter. I cannot seem to figure out how to select multiple rows to apply an effect to, or expand the effect from a single row to multiple rows?

To apply an effect to multiple channels, you can do one of two things.

1. Put the channels into a group. Apply the effect to the group, and it will apply to those channels.
2. Just drag the same effect to the next channel. If you want to change it length, you will have to do those individually.

Hope that makes sense.

Erik

g8rfn
11-29-2011, 11:31 PM
Hmmm. I tried applying it on the group row, and cant seem to get that to work either. Just made a simple 10 channel setup with the preview "circles" in a line and was trying both chase and spin. Perhaps i am doing something wrong in the actual preview window setup? I cant even get a single node to display in preview using a set level effect.

plasmata
11-29-2011, 11:40 PM
Applying it to the group worked fine for me. Not to be funny but are you sure that your preview setup has a dot for each of the channels that are in the group?

g8rfn
11-29-2011, 11:47 PM
NM, got it... Thought I could get away with skipping the "setup patch" step. Answer... no. :-) Works now!

burcjo
11-30-2011, 04:51 PM
How are we on the bugs and tracking?

This stuff looks REALLY AWESOME! Thank You guys for all your hard work. I recognize the greatness that's gone into this. I'm really excited about getting into this. The grouping feature alone is worth it's weight in gold. You guys rock!

I've got it running here at work, I play with it on lunch hour. I'm running Windows 7 SP1 64bit, 4GB Ram and Dual 3.Ghz processors. When I go into edit preview setup, I can make all kinds of cool stuff, but when I exit Vixen, it all goes away. Even if I do something simple like setting background, that goes away too. Maybe I missed something in the compatibility section...

Thank You again for all your work on this!

ppohlman
11-30-2011, 06:01 PM
I finally had some time to play around with Vixen 3.0. Great work! It will definitely take a little while getting use to the new way to sequence.
I don't know if all of these are bugs/issues or things that I just missed, but I'll list them anyways.


When creating a group, the new window title is "Node Name". Should it be "Group Name"?
When multiple effects are overlapped on the same channel/group, the latter effects don't show the adjusting bar (<-->) on the left side of the effect.
Is it possible to drag the marker lines while in the Sequence Editor window?
Is there a way to see the associated audio wave forms? (this may be a plug-in request)
Is there a way to choose the color of a node or channel for static lights (non-RGB) and have that color show in the effects on that channel?


I'm not sure if there is a thread for Display Previewer issues, so I'll post this list here as well.

The editor window size keeps changing size when opened. It appears that ALL channels are visible. If there are high channel counts, the window goes off of the screen.
Is there a way of choosing colors, or passing in info from the node/channel setup in vixen?
When changing the "shape", it doesn't update in the editor until after I have run/played the sequence in vixen.
Nodes seem to stay on the last known level after an effect has finished instead of turning "off".
Is there an option to save different setups?
The setup doesn't save when you shutdown Vixen.
In the editor, it is possible to draw/create multiple shapes for one node, but during playback only the first shape is shown.
After an element has been drawn/created, it would be nice to be able to re-size the element in the main window to fit the background image. Currently, you can click and drag the size of the element box, but the shapes do not re-size with it. It seems to be more like a "crop" feature.
Is it possible to copy/paste elements and remap them to new channels? It would be nice to create one mini-tree and then copy that many times instead of re-creating it every time for each element.


Hope these lists help.

DynamoBen
11-30-2011, 06:35 PM
How are we on the bugs and tracking?

The tracking system has been up and running for some time but wasn't setup for public use. We are still making changes to make it public and reachable but its taking longer than we had hoped. I expect we should be go to go in the coming days barring any more issues.

sallz0r
11-30-2011, 09:31 PM
I finally had some time to play around with Vixen 3.0. Great work! It will definitely take a little while getting use to the new way to sequence.
I don't know if all of these are bugs/issues or things that I just missed, but I'll list them anyways.

Thanks for all of that. Some are known issues/features that are needed, and we just haven't had time to implement (eg. the audio wave form, channel colors, etc.), and some are new. Hopefully the bug tracker will be public soon, and we can put them all in there. :-)

Macrosill
12-01-2011, 10:26 AM
To apply an effect to multiple channels, you can do one of two things.

1. Put the channels into a group. Apply the effect to the group, and it will apply to those channels.
2. Just drag the same effect to the next channel. If you want to change it length, you will have to do those individually.

Hope that makes sense.

Erik

Maybe I am not understanding but when I drag an effect from one channel to another it simply moves the effect, it does not copy the effect. I tried shift drag and alt drag.


On a side note:
I was just playing with the chase effect. I made a chase effect across 16 channels in a group, how easy that was. I also edited the effect by changing the individual pulses to not only fade on but also fade off with a 500ms pulse overlap. How easy it was to adjust the chase across 16 channels by only having to edit a single effect for the whole group. Kudos to the team!

kychristmas
12-01-2011, 10:31 AM
This thread is making it hard for me to stay away from Vixen 3.0 beta. I need to focus on work and getting the rest of my display up, but this looks so promising. I told myself I need to wait until after the holidays, but it doesn't look like that will happen :) I know if I open it up and get into it, I'll be done and drop the ball on everything else.

ppohlman
12-01-2011, 10:48 AM
Maybe I am not understanding but when I drag an effect from one channel to another it simply moves the effect, it does not copy the effect. I tried shift drag and alt drag.

I think he meant that you need to drag a "new" effect from the toolbar into the additional channel.

sallz0r
12-01-2011, 10:53 AM
Maybe I am not understanding but when I drag an effect from one channel to another it simply moves the effect, it does not copy the effect. I tried shift drag and alt drag.

At the moment, the only way to copy an effect is the good 'ol copy-paste (CTRL-C, CTRL-V), or from the 'Edit' menu, I believe.

I like the shift-dragging idea as well, though, or something like that. That could work. Something to go in the feature requests in the bug tracker. (I think it's almost live!).

Materdaddy
12-01-2011, 12:38 PM
At the moment, the only way to copy an effect is the good 'ol copy-paste (CTRL-C, CTRL-V), or from the 'Edit' menu, I believe.

I like the shift-dragging idea as well, though, or something like that. That could work. Something to go in the feature requests in the bug tracker. (I think it's almost live!).

If that is a "yet to be implemented" feature, I would suggest using Ctrl+drag for copy to conform to windows' methods of file dragging/dropping. Shift+drag is to move something that is by default copied (cross-drive) or default shortcut (dragging exes to menus).

erm213
12-01-2011, 06:25 PM
I think he meant that you need to drag a "new" effect from the toolbar into the additional channel.

Yep, that was what I meant to say!

Thanks,

Erik

plasmata
12-01-2011, 10:49 PM
I finally had some time to play around with Vixen 3.0. Great work! It will definitely take a little while getting use to the new way to sequence.
I don't know if all of these are bugs/issues or things that I just missed, but I'll list them anyways.


When creating a group, the new window title is "Node Name". Should it be "Group Name"?
When multiple effects are overlapped on the same channel/group, the latter effects don't show the adjusting bar (<-->) on the left side of the effect.
Is it possible to drag the marker lines while in the Sequence Editor window?
Is there a way to see the associated audio wave forms? (this may be a plug-in request)
Is there a way to choose the color of a node or channel for static lights (non-RGB) and have that color show in the effects on that channel?


I'm not sure if there is a thread for Display Previewer issues, so I'll post this list here as well.

The editor window size keeps changing size when opened. It appears that ALL channels are visible. If there are high channel counts, the window goes off of the screen.
Is there a way of choosing colors, or passing in info from the node/channel setup in vixen?
When changing the "shape", it doesn't update in the editor until after I have run/played the sequence in vixen.
Nodes seem to stay on the last known level after an effect has finished instead of turning "off".
Is there an option to save different setups?
The setup doesn't save when you shutdown Vixen.
In the editor, it is possible to draw/create multiple shapes for one node, but during playback only the first shape is shown.
After an element has been drawn/created, it would be nice to be able to re-size the element in the main window to fit the background image. Currently, you can click and drag the size of the element box, but the shapes do not re-size with it. It seems to be more like a "crop" feature.
Is it possible to copy/paste elements and remap them to new channels? It would be nice to create one mini-tree and then copy that many times instead of re-creating it every time for each element.


Hope these lists help.
I had the same issue with the Display Previewer not saving my design but I found that if I changed the Display Element name from the default of "New Display Item" it was there when I reopened Vixen.

erm213
12-01-2011, 10:57 PM
I had the same issue with the Display Previewer not saving my design but I found that if I changed the Display Element name from the default of "New Display Item" it was there when I reopened Vixen.

Hmmm, I can not recreate this issue of not saving. Can I get the ModuleStore.xml file in your My Documents\Vixen\System Data folder.

Thanks,

Erik

95CivicSi
12-02-2011, 12:17 AM
Just wanted to offer a new logo for Vixen as requested in the beta. Here it is.


**EDIT:Sorry the animated GIF doesn't work on the PHP side so here's the full pic.**

12440

Reddy_Kilowatt
12-02-2011, 12:26 AM
:thup2: Cool!

-Craig

zaker
12-04-2011, 11:44 AM
Using 3.0 beta for some testing RGB light strips on a Ren48lsd. Works great on the renard, using individual channels. I made a group of Ch 1,2,3,4 called it RGB1, apply anything to that group, light strip works, just as white as all channels are getting the same signals. Added RGB properties, told it to split the channels, but have no other options to set which channel is which color.

Is RGB not fully implemented, or did I miss a step? This seems like it is going to be so much easier with 3.0!

sallz0r
12-04-2011, 05:36 PM
Using 3.0 beta for some testing RGB light strips on a Ren48lsd. Works great on the renard, using individual channels. I made a group of Ch 1,2,3,4 called it RGB1, apply anything to that group, light strip works, just as white as all channels are getting the same signals. Added RGB properties, told it to split the channels, but have no other options to set which channel is which color.

Is RGB not fully implemented, or did I miss a step? This seems like it is going to be so much easier with 3.0!

To configure RGB with individual channels, put the individual color channels into a group, then give the group the RGB property. When you configure the RGB property, you have the option to break it into individual channels; select the appropriate channel for each color.

Aurbo99
12-04-2011, 05:43 PM
Just wanted to offer a new logo for Vixen as requested in the beta. Here it is.


**EDIT:Sorry the animated GIF doesn't work on the PHP side so here's the full pic.**


12440



Nice gif! +1 from me..

Can you flip the gif so its facing "forward" =)

zaker
12-04-2011, 06:21 PM
To configure RGB with individual channels, put the individual color channels into a group, then give the group the RGB property. When you configure the RGB property, you have the option to break it into individual channels; select the appropriate channel for each color.

Thanks, it works now! I had to add ALL of the channels from the controller, THEN group them.

boarder3
12-04-2011, 07:22 PM
Does anyone know if 3.0 will get layers and virtual controllers that would be great.

sallz0r
12-04-2011, 07:46 PM
Does anyone know if 3.0 will get layers and virtual controllers that would be great.

Can you describe what you mean by layers, and by virtual controllers? What are you trying to achieve with them?

DynamoBen
12-05-2011, 12:03 AM
The bug tracker is open for business. We think we have everything sorted and are ready to accept bugs. There are two ways to report a bug via email, or directly in the system.

Email: Send an email to bugs@vixenlights.com, the body of the text will be submitted as a bug report and you will receive confirmation that it was entered. In addition the system will automatically create an account for you if you don't already have one.

To add a comment to an existing bug just reply with the bug ID in the subject of the email, the body of the text will be added as a comment.

Direct: Go to bugs.vixenlights.com (http://bugs.vixenlights.com)and register. Once you have registered you can submit and review bugs directly in the system.

Bug report tips: Please provide as much information as is necessary to reproduce the problem, steps to reproduce are critical! For more tips on good bug writing go here (http://www.softwaretestinghelp.com/how-to-write-good-bug-report/).

Thanks,

Vixen 3.0 Team

Hogfather
12-05-2011, 12:56 AM
Really looking forward to playing with this at the beginning of the year. Thanks to all the developers for your efforts! I love Vixen!

Oh, BTW ya'll should make little Vixen bumper stickers with your reindeer logo. I'd totally buy 4 or 5 of them!

Materdaddy
12-05-2011, 12:58 AM
The bug tracker is open for business. We think we have everything sorted and are ready to accept bugs. There are two ways to report a bug via email, or directly in the system.

Email: Send an email to bugs@vixenlights.com, the body of the text will be submitted as a bug report and you will receive confirmation that it was entered. In addition the system will automatically create an account for you if you don't already have one.

To add a comment to an existing bug just reply with the bug ID in the subject of the email, the body of the text will be added as a comment.

Direct: Go to bugs.vixenlights.com (http://bugs.vixenlights.com)and register. Once you have registered you can submit and review bugs directly in the system.

Bug report tips: Please provide as much information as is necessary to reproduce the problem, steps to reproduce are critical! For more tips on good bug writing go here (http://www.softwaretestinghelp.com/how-to-write-good-bug-report/).

Thanks,

Vixen 3.0 Team

Yay! Reported VIX-89.

Thanks KC, Ben, Erik, and team!

Materdaddy
12-05-2011, 12:59 AM
Really looking forward to playing with this at the beginning of the year. Thanks to all the developers for your efforts! I love Vixen!

Oh, BTW ya'll should make little Vixen bumper stickers with your reindeer logo. I'd totally buy 4 or 5 of them!

Speaking of the logo... I don't think the logo should be changed w/ the new version... isn't "powered by vixen" with the logo on about 80% of the DIYC hardware? :cry:

dpitts
12-05-2011, 01:09 AM
Layers and virtual controllers are LightShow Pro terms. Layers are a group of channels that you can apply a "Transition" to. Transitions are effects that are generated by avi videos. The video is mapped to the layer (group of channels). The mapping is based on the 2d placement of the channel drawn on the preview (channel image). I believe Vixen's groups are similar to layers. Although a particular channel can be part of many groups in Vixen but in LSP a channel can only be in one layer. The one to multiple relationship in Vixen will be powerful.

A virtual controller in LSP is a way to group channels. Channels in LSP are created by creating a controller. If you want to group channels that are from different controllers you have to create a virtual controller and add them to it. Again groups in Vixen will take care of this also.




Can you describe what you mean by layers, and by virtual controllers? What are you trying to achieve with them?

sallz0r
12-05-2011, 06:56 AM
Layers and virtual controllers are LightShow Pro terms. Layers are a group of channels that you can apply a "Transition" to. Transitions are effects that are generated by avi videos. The video is mapped to the layer (group of channels). The mapping is based on the 2d placement of the channel drawn on the preview (channel image). I believe Vixen's groups are similar to layers. Although a particular channel can be part of many groups in Vixen but in LSP a channel can only be in one layer. The one to multiple relationship in Vixen will be powerful.

Yeap, that's exactly it. Groups are just abstract groupings of nodes (other groups/channels) -- using properties, you can define a group to be something in particular (like a color) or have something (like a position or status or something). So, while something like what you talk about isn't possible at the moment, it would fit in well with the overall concept -- we could make a new property module that lets users configure channels into a 'grid' or some sort of placement, then an effect can be written that uses that property and renders it as appropriate.



A virtual controller in LSP is a way to group channels. Channels in LSP are created by creating a controller. If you want to group channels that are from different controllers you have to create a virtual controller and add them to it. Again groups in Vixen will take care of this also.

Yeah; instead of being controller-centric (like 2.x, and from how I assume LSP works from what you say), 3.x is more designed to be used in the 'logical' space instead: you can set up all the channels, groups, properties, and even sequence an entire thing if needed, and you can patch the channels to the controller outputs later on. Or if you change controllers or systems, it's easy enough to transpose old data to new systems.

Well, that's the idea, at least. ;-)

DynamoBen
12-05-2011, 12:10 PM
The email submission wasn't working but now it is fixed. If you submit/submitted a bug via email and don't/didn't receive an acknowledgement it didn't work.

bnradams
12-06-2011, 06:47 PM
Maybe its a little late for a feature request, but until I started playing with the drag-&-drop effects vs the good old fashioned grid did I think of this. It would be nice to be able to have a 'snap-to' for the effects timing, eg. If you have pre-determined markers or an effect on another node you could drag an effect to another node and have it automatically 'snap-to' the start time of the other effect. Or be able to re-size an effect and have the start or end time 'snap-to' the same time on another effect. The same can be accomplished by directly editing the effects time in the 'properties' window but it would be nice to have this feature directly in the editor to save time.

DynamoBen
12-06-2011, 06:54 PM
Maybe its a little late for a feature request, but until I started playing with the drag-&-drop effects vs the good old fashioned grid did I think of this. It would be nice to be able to have a 'snap-to' for the effects timing, eg. If you have pre-determined markers or an effect on another node you could drag an effect to another node and have it automatically 'snap-to' the start time of the other effect. Or be able to re-size an effect and have the start or end time 'snap-to' the same time on another effect. The same can be accomplished by directly editing the effects time in the 'properties' window but it would be nice to have this feature directly in the editor to save time.

Feel free to submit this as a bug, then we will have it in the tracker for future releases.

sallz0r
12-06-2011, 08:44 PM
Maybe its a little late for a feature request, but until I started playing with the drag-&-drop effects vs the good old fashioned grid did I think of this. It would be nice to be able to have a 'snap-to' for the effects timing, eg. If you have pre-determined markers or an effect on another node you could drag an effect to another node and have it automatically 'snap-to' the start time of the other effect. Or be able to re-size an effect and have the start or end time 'snap-to' the same time on another effect. The same can be accomplished by directly editing the effects time in the 'properties' window but it would be nice to have this feature directly in the editor to save time.

Unless I'm misunderstanding what you want, this is already there. If you drag effects around, they will snap to edges of other effects, and to any marks in the sequence.

The mark level will dictate how 'snappy' it will be -- eg. marks of level 1 will only snap within 2 pixels (from memory), and marks of level 10 are about 20 pixels, I believe.

Is that what you mean?

bnradams
12-07-2011, 09:18 AM
Unless I'm misunderstanding what you want, this is already there. If you drag effects around, they will snap to edges of other effects, and to any marks in the sequence.

The mark level will dictate how 'snappy' it will be -- eg. marks of level 1 will only snap within 2 pixels (from memory), and marks of level 10 are about 20 pixels, I believe.

Is that what you mean?

Got it, I didn't play with the 'weight' of the markers. At default level 1, the 'snap' is barely noticeable but still there. After increasing the 'weight' of the marker the 'snap' is much more noticeable. In order to snap to another effect, both effects have to be on the same node. Simply drag your new effect over the top of the originating effect, adjust start or stop time, then drag the adjusted effect to the desired node.

sallz0r
12-07-2011, 09:31 AM
In order to snap to another effect, both effects have to be on the same node. Simply drag your new effect over the top of the originating effect, adjust start or stop time, then drag the adjusted effect to the desired node.

Actually, that's a bug I found a while ago that I've since forgotten about until you mentioned it -- if you drag an effect ACROSS rows, it stops snapping to other effects. You have to release, then redrag in the same row for it to snap to other effects properly. :-)

Feel free to ticket it if you want, I'll get to fixing all those sort of things early in the new year.

ppohlman
12-07-2011, 04:04 PM
Is there a way (that I'm not seeing) to combine effects? For example, I want to have a mega tree fade while spinning.

Is this the type of thing you want us to log into the bug tracker?

CaptKirk
12-07-2011, 05:22 PM
Did the Entec Pro capability mentioned way earlier in the thread get any traction??

erm213
12-07-2011, 07:05 PM
Did the Entec Pro capability mentioned way earlier in the thread get any traction??

It's close. I need to do some device testing on it, then it should be ready.

Erik

sallz0r
12-07-2011, 07:46 PM
Is there a way (that I'm not seeing) to combine effects? For example, I want to have a mega tree fade while spinning.

Is this the type of thing you want us to log into the bug tracker?

No, there's currently not any way to do anything like that. It's a difficult problem to abstract out into something suitably generic, so we're not sure on the best way to do it. I've been pondering it for a while.

But yes, by all means, feel free to make a ticket for it. Make a ticket for *any* bug, feature request, etc.; worst case, we'll just close it with an explanation of why it isn't a bug (intended behaviour, etc.) or if it's not a feature we'll support. But best case, we'll implement it and track changes against the ticket. :-)

Matt_Edwards
12-07-2011, 09:45 PM
It's close. I need to do some device testing on it, then it should be ready.

Erik
:thup: :biggrin: :thup:

Jrd
12-09-2011, 04:20 AM
Resizing/regenerating effects seems to take a while with a Twinkle on an eight channel group over 10+ seconds. Maybe effects could be resized and regenerated separately?

XP Home SP3, 2.6Ghz Processor, 512MB RAM Only Vixen running.


Speaking of the logo... I don't think the logo should be changed w/ the new version... isn't "powered by vixen" with the logo on about 80% of the DIYC hardware? :cry:

I feel the same way, Or at least the design should sty the same.


Hmmm, I can not recreate this issue of not saving. Can I get the ModuleStore.xml file in your My Documents\Vixen\System Data folder.

Thanks,

Erik

Interesting, ModuleStore.xml doesn't save until you close Vixen and it looks empty:

<?xml version="1.0" encoding="utf-8"?>
<ModuleStore version="1">
<ModuleData>
<ModuleDataSet />
</ModuleData>
</ModuleStore>

And my Display Preview was also lost, other settings appear to be in place though.

sallz0r
12-09-2011, 04:34 AM
Resizing/regenerating effects seems to take a while with a Twinkle on an eight channel group over 10+ seconds. Maybe effects could be resized and regenerated separately?

Yes, that's horrendously inefficient and slow at the moment. I'm investigating other fixes, at the moment it's just something quick and simple to get the intended functionality out there. Just not efficient yet. :-)


Interesting, ModuleStore.xml doesn't save until you close Vixen and it looks empty:

<?xml version="1.0" encoding="utf-8"?>
<ModuleStore version="1">
<ModuleData>
<ModuleDataSet />
</ModuleData>
</ModuleStore>

And my Display Preview was also lost, other settings appear to be in place though.

That's correct, that module store isn't written until the whole application is closed. Not sure why the display preview data isn't being persisted, though..... after you close the setup for it, and reopen it, is everything still in there?

What's in your log files? Anything of interest? (Exceptions/crashes?)

plasmata
12-09-2011, 11:12 AM
Not sure why the display preview data isn't being persisted, though..... after you close the setup for it, and reopen it, is everything still in there?

What's in your log files? Anything of interest? (Exceptions/crashes?)
As I mentioned earlier in this thread I had the same issue with the Display Previewer not saving my design but I found that if I changed the Display Element name from the default of "New Display Item" my preview was there when I reopened Vixen. Maybe it was just a coincidence but I'm hoping it gives you a clue to the solution. Maybe initializing the preview overwrites the saved one if you don't change the default name?

tlorek
12-09-2011, 04:01 PM
I'm planning on doing some playing around with 3.0 before I take my display down. It would be nice if there was an upgrade tool for sequences and profiles. Any chance of that being possible this month?

sallz0r
12-09-2011, 08:38 PM
I'm planning on doing some playing around with 3.0 before I take my display down. It would be nice if there was an upgrade tool for sequences and profiles. Any chance of that being possible this month?

You mean an upgrade from 2.x sequences? Pretty unlikely, unfortunately (unless someone else corrects me! :-) ). Since it's a completely different format of data, and a completely different way of doing it all, it's pretty hard to convert between the two, and would need a fair bit of time and thought to get right.

Best case, you'll end up with a sequence that has tens of thousands of tiny individual "Set Level" effects, as though all your effects have already been rasterized down to discrete values. That in itself would be hard to work with, and may present other problems we can't forsee.

It's definitely something we want to look into; just something that's non-trivial.

budude
12-09-2011, 09:10 PM
You mean an upgrade from 2.x sequences? Pretty unlikely, unfortunately (unless someone else corrects me! :-) ). Since it's a completely different format of data, and a completely different way of doing it all, it's pretty hard to convert between the two, and would need a fair bit of time and thought to get right.

Best case, you'll end up with a sequence that has tens of thousands of tiny individual "Set Level" effects, as though all your effects have already been rasterized down to discrete values. That in itself would be hard to work with, and may present other problems we can't forsee.

It's definitely something we want to look into; just something that's non-trivial.

Hmm - that may be a big hitter for many folks - it was indeed originally alluded to that this would/will work - see the bottom of this post: http://doityourselfchristmas.com/forums/showthread.php?16397-Vixen-3-0-Introduction-Series-Part-1&p=166391#post166391. IMHO it will definitely mean a much diminished amount of testing while everyone's stuff is up now unless they want to rewrite sequences from scratch again - personally I'm "sequenced out"...

sallz0r
12-09-2011, 10:01 PM
Hmm - that may be a big hitter for many folks - it was indeed originally alluded to that this would/will work - see the bottom of this post: http://doityourselfchristmas.com/forums/showthread.php?16397-Vixen-3-0-Introduction-Series-Part-1&p=166391#post166391. IMHO it will definitely mean a much diminished amount of testing while everyone's stuff is up now unless they want to rewrite sequences from scratch again - personally I'm "sequenced out"...

Yeah, I definitely agree -- and I know we do plan on having some sort of conversion process available. I just don't know how likely that is going to be in the next few weeks. Having said that, though, even if the old sequences can't be used just yet, there's still a lot of other things that can still be tested?

Teddy
12-10-2011, 04:27 AM
maybe ive missed it but how do you do the classic on off on off on off in 3.0 do i have to drag a set effect in at each interval and turn the ch to 100 then to 0 and then rinse and then invert that for the next channel or have i missed something. ive looked at it for like 45 minutes now and cant for the life of me figure out how to do classic sequencing for a small back and fourth

sallz0r
12-10-2011, 06:38 AM
maybe ive missed it but how do you do the classic on off on off on off in 3.0 do i have to drag a set effect in at each interval and turn the ch to 100 then to 0 and then rinse and then invert that for the next channel or have i missed something. ive looked at it for like 45 minutes now and cant for the life of me figure out how to do classic sequencing for a small back and fourth

It's a completely different style of sequencing; so if you want discrete values, then yes, a set level effect would be what you're after.

However, having said that, normally in 2.x those discrete values were usually part of a bigger effect -- a spin, a chase, a pulse, etc., so those effects are there as well, and hopefully you'll be able to find more use out of them instead! :-) But if not, then setting a bunch of specific set level effects would be the way to go, if you'd prefer that.

Teddy
12-10-2011, 01:25 PM
It's a completely different style of sequencing; so if you want discrete values, then yes, a set level effect would be what you're after.

However, having said that, normally in 2.x those discrete values were usually part of a bigger effect -- a spin, a chase, a pulse, etc., so those effects are there as well, and hopefully you'll be able to find more use out of them instead! :-) But if not, then setting a bunch of specific set level effects would be the way to go, if you'd prefer that.



Hmmm ok. I'll have to play with it some more when a new version comes out. Maybe it's just the way I figured out how to sequence this year but the idea is a bit confusing for me. I'm sure it's awesome for you guys who have crazy displays but I just have 48 Chs that I've just been bouncing to the different beats of the music. I guess the beauty of 3.0 is that if you don't like something you can write a plugin to fix it. I also realize that this is in early beta so there are things to Come. I just wanted to get some feed back because it seemed like the new method was More confusing then the old one.

bnradams
12-10-2011, 01:52 PM
Maybe some of the code experts could come up with a 'Vixen Classic' effect that could be used to simulate the old grid that you could apply to a node and 'copy-paste' old sequence data into. Just a thought...

Jrd
12-11-2011, 01:27 AM
Yes, that's horrendously inefficient and slow at the moment. I'm investigating other fixes, at the moment it's just something quick and simple to get the intended functionality out there. Just not efficient yet. :-)

Alright, just pointing it out. :)


That's correct, that module store isn't written until the whole application is closed. Not sure why the display preview data isn't being persisted, though..... after you close the setup for it, and reopen it, is everything still in there?

Yes, as long as i don't close Vixen I can open and close the setup as much as I want and it is all there.


What's in your log files? Anything of interest? (Exceptions/crashes?)

Just System and Execution Engine starting and stopping in Info.log


As I mentioned earlier in this thread I had the same issue with the Display Previewer not saving my design but I found that if I changed the Display Element name from the default of "New Display Item" my preview was there when I reopened Vixen. Maybe it was just a coincidence but I'm hoping it gives you a clue to the solution. Maybe initializing the preview overwrites the saved one if you don't change the default name?

I'm pretty sure I named everything, although it took a few tries to figure out the new interface.


Maybe some of the code experts could come up with a 'Vixen Classic' effect that could be used to simulate the old grid that you could apply to a node and 'copy-paste' old sequence data into. Just a thought...

That sounds like it would be a good idea. "Vixen Classic/Manual Mode"

aussiephil
12-11-2011, 09:40 AM
KC and the Development team,

This is looking like a great step forward into the world of object based sequencing that has long been spoken about. After reading all the posts and spending a few hours playing with it and then contemplating just how i could translate my display in Vixen3 i have a couple of observations.

The Channels and Groups window is likely more confusing than it could be. An option to hide individual nodes if they are grouped would be essential for large displays. If you are going to use the "patch" functionality to it's limits then being able to define nodes that consist of multiple channels in one step would be good.
Some one correct me if i'm wrong but at the moment if i want to create a node that is a (for example) 112 Pixel RGB string it seems i have to create all 112 pixels as 112 RGB Nodes and then group them as one string, then repeat for x number of strings I have.
If that's the case then some sort of import from say a spreadsheet would be handy. maybe a channel import module, the SystemConfig.xml looks straightforward except for the GUID ID used.
The sequencing interface looks and works well, however same comment from above, if you group nodes into a group for an object then they should be hidden unless optionally un-hidden.

I'd be happy to send the dev's a copy of my channel allocation spreadsheet from this year, 7744 Vixen channels with everything broken down into Features and functions within the features complete with the channel mapping back to output devices, if this could be helpful.

The sad bit is V3.0 won't at this time let me do my video sequencing workaround that i have used with 2.5 for the last two years unless someone writes a classic interface module to allow for discrete cells like v2.x.

I will be very interested to test this once it gets DMX and E131 outputs and do a direct performance comparison to 2.5, currently 2.5 is not even using 1% of the processor on the show computer to output 7744 channels at 25ms timings. This for me is the key, the ability to output all the channels without missing data.

Back to the Channels and Groups window, the properties section in the bottom right seems logically out of place if the goal is to separate the nodes from the output. thinking about it as I typed this I would personally have a completely separate admin screen to manage the mapping from objects (nodes) to physical output devices. Certainly for larger channel counts or lots of objects this may make sense.

Next thought, grouped nodes should be able to have the effects they can handle assigned in management window along with the defaults for that effect when used with that group, then in the sequencer when dragging and dropping effects a quick check could be made on mouse up whether the group accepts that effect and only drop if yes. This could then open up a select then right click to get the effect to apply to that group ability, this may become highly desirable if effects become easy to write. For example an RGB megatree would have a spiral effect and wipe effects define along with the spin. The wipe effect could have properties like direction (up,down, left right) maybe expressed in degrees to do diagonal wipes etc.

anyway, Congrats to the team for the work so far.

Cheers

aussiephil
12-11-2011, 08:37 PM
Some further thoughts on 3.0

Just to clarify, none of the below is a direct feature/functionality request but more a set of thoughts for the developers to either say "yep, already considered that" or "nope, not possible" or anything in between.
I'll try and express each in what i term a "use case" scenario.

Knowing we have yet to see the music sequencing possibilities....

Having worked with LSP this year the audio scrubbing functionality combined with the ability to quickly set timing marks with the mouse allows very accurate setting of beat marks.

Use case: Drag effect onto node group and rather than use discrete "do x for this time" the properties read in the timing marks set during that period and the effect is then controlled by the user set timing marks. Assume spin effect. Options may be. Spin frequency and durations set by number of timing marks and duration between each mark or step frequency of spin may be the timing mark points.

Use case: Minitree is part of Minitree Group and part of Red Group. Minitrees are currently in a chase for the chorus but at the same time you wish to fade all Red items up to 100% as you set up a red to green sweep in the three timing marks at end of chorus.
Which effect has priority? Will this even work? Actually doing it in the sequencer seems to work but how is the output handled?

expanding on KC's post about weighting effects across the yard by distance 20%,60%,20% i think was the examples.
Use case: Apply a sweep effect so blue washed down a megatree with 56 vertical pixels then across a yard with 12 rows of RGB elements and back up second tree with 56 vertical pixels, total rows tranversed 124, total groups 3. Sweep effect could be controlled by total rows, number of groups, fixed time steps or even timing marks as per previous cases.
This introduces the concept of weighting by rows/pixels or bulb counts.

Back to general thoughts.
For very high channel counts the ability to hide nodes/groups/channels is highly desirable to keep the sequencing interface as clean as possible
In LSP this year I had 18 layers set up that are essentially groups in Vixen3, this would easily be more using the grouping concept.
Use Case: Megatree is made up of both RGB and Non RGB strings, hiding each would be desirable when working in each of the colour spaces.

Having finally played lots with LSP this year one of it's strengths is to apply effects across groups of channels. A major weakness is it's near complete lack of support for multithreading and multi-processors, in the days of 6 and 8 core processors this is a major issue.
I didn't check if Vixen3 was using more that 1 core, i seriously hope it does.

sallz0r
12-11-2011, 09:22 PM
The Channels and Groups window is likely more confusing than it could be. An option to hide individual nodes if they are grouped would be essential for large displays. If you are going to use the "patch" functionality to it's limits then being able to define nodes that consist of multiple channels in one step would be good.
Some one correct me if i'm wrong but at the moment if i want to create a node that is a (for example) 112 Pixel RGB string it seems i have to create all 112 pixels as 112 RGB Nodes and then group them as one string, then repeat for x number of strings I have.

I'm not sure that I completely understand you; however, you are able to have nodes that exist only in groups, so you don't have to have them all at a root/base level. For example, I've got ~1200 channels, and I've only got about 15 or so groups at the base level: things like "Minitrees", "Arches", "Treeline", etc. Then in the "Minitrees" group I have ~20 more groups -- Minitree-1 through to Minitree-20 -- then each of those has an R, G and a B channel in it. So when sequencing or configuring anything, I pretty much never see each inidividual R, G or B node, as I'm always working at a group level, or an individual item level.



If that's the case then some sort of import from say a spreadsheet would be handy. maybe a channel import module, the SystemConfig.xml looks straightforward except for the GUID ID used.

Yeah, importing them would be handy... just a case of figuring out the best format and what data is needed. Maybe something from CSV could work, since I'm guessing a lot of people organize stuff from spreadsheets....


I'd be happy to send the dev's a copy of my channel allocation spreadsheet from this year, 7744 Vixen channels with everything broken down into Features and functions within the features complete with the channel mapping back to output devices, if this could be helpful.

If you'd like, make a ticket (feature request for importing data) in the bug tracker -- details earlier in the thread -- and attach the files there, then we have some samples of how the community uses it. That would be handy, as we can see the info and discuss it all from there.


The sad bit is V3.0 won't at this time let me do my video sequencing workaround that i have used with 2.5 for the last two years unless someone writes a classic interface module to allow for discrete cells like v2.x.

Can you expand on this a bit? What exactly are you trying to do?

I haven't used any video or pixel displays myself, which is why there's no modules to support it at the moment; however, we've considered and discussed this in the development. For example, we plan on writing a few modules to make something like this fairly straightforward:

1) a 'grid' property, or 'display' property, or something like that -- which you can use to configure a group as a grid of pixels. This would provide information to allow effects to address the group as a 'grid', or a rectangular pixel display.
2) effects that can utilize the grid property -- such as a 'show picture' effect, or a 'play video' effect.

That way, instead of having the existing solution -- which as I understand it, is a simple one-way conversion from a picture or video to a set of discrete channel values, using a predefined configuration of a grid display -- we have all the information needed in the user's display configuration, which allows us to calculate all the information in the software. That will make it many times easier to configure, maintain, etc. (Changing grid size? Easy, just modify the display config to suit. Everything else just works.)

In essence, it's keeping with the whole concept of "modelling the user's intent", rather than making them figure out everything to a low level and having data hard coded. Getting enough information about the display to make it work as intended.


I will be very interested to test this once it gets DMX and E131 outputs and do a direct performance comparison to 2.5, currently 2.5 is not even using 1% of the processor on the show computer to output 7744 channels at 25ms timings. This for me is the key, the ability to output all the channels without missing data.

Sure. I know Erik was working on some of the other output modules -- I *think* E1.31 was one of them -- but the problem is, without having the hardware to play with, it's hard to wrote plugins and test them.

It should be relatively efficient; there's the ability for a sequence to pre-render all of these complex effects down to discrete commands before real-time, so ultimately, it should be easy enough to have the sequences rendered down to a huge blob of discrete commands, then that is just iterated through at run time.

I would hazard a guess that it's not going to be as efficient as 2.5, since the execution engine is a bit more complex now, but we're still aiming for performance.


Back to the Channels and Groups window, the properties section in the bottom right seems logically out of place if the goal is to separate the nodes from the output. thinking about it as I typed this I would personally have a completely separate admin screen to manage the mapping from objects (nodes) to physical output devices. Certainly for larger channel counts or lots of objects this may make sense.

I'm not sure I follow you. the properties are for information about a particular node -- a channel or a group -- and doesn't have anything to do with what is outputting the data for that channel. It's probably not 100% clear, since I think there's only the RGB property in that release, but the concept is for properties to allow you to define information about your display. For example, say you have a fictional property module that lets you define the size of display items. You might say "this group, 'megatree', is 6.0m tall" using the property, and you might define some minitrees to be 0.5m tall. Then, later on, you might have an effect which can use this information, and which might light up items in order from smallest to biggest.

Not a great example, but hopefully you get the idea. :-) At no point does the property have anything to do with the actual physical output -- it's just defining some information about the group at a logical display level.

If there needs to be information about outputs defined, then the only thing we have at the moment are transforms -- like dimming curves. These have to be at the output level, since it's dependent on the actual lights and/or outputs that are on that output. However, it's nowhere near as powerful, since it's got to be processed live, in realtime -- whereas property information can be used ahead of time, in effects, to generate the data.


Next thought, grouped nodes should be able to have the effects they can handle assigned in management window along with the defaults for that effect when used with that group, then in the sequencer when dragging and dropping effects a quick check could be made on mouse up whether the group accepts that effect and only drop if yes. This could then open up a select then right click to get the effect to apply to that group ability, this may become highly desirable if effects become easy to write. For example an RGB megatree would have a spiral effect and wipe effects define along with the spin. The wipe effect could have properties like direction (up,down, left right) maybe expressed in degrees to do diagonal wipes etc.

True, however it was a conscious decision to allow any effects to apply to any groups. We don't want to arbitrarily restrict what users can do, since it's quite often that the software is used in ways we couldn't even begin to imagine. Additionally, it introduces complexity with the dragging off effects around (in particular, between channels) in the sequencer.

Thanks for your feedback and comments. Hopefully I've shed some light on some of the issues. If you find bugs, or have feature requests, feel free to make tickets for them! It's the best way we have to track development, and keep things moving.

Cheers!

sallz0r
12-11-2011, 10:34 PM
... the ability to quickly set timing marks with the mouse allows very accurate setting of beat marks.

Yeah, I want to make working with marks a bit easier. I'm just not sure how, yet. But it could definitely be better integrated with the grid display, rather than having to be done in a separate configuration form.

[/QUOTE]

Use case: Drag effect onto node group and rather than use discrete "do x for this time" the properties read in the timing marks set during that period and the effect is then controlled by the user set timing marks. Assume spin effect. Options may be. Spin frequency and durations set by number of timing marks and duration between each mark or step frequency of spin may be the timing mark points.

Hmm, that's an interesting idea; having marks being able to be used by effects. Breaks a bit of the logical separation we had, but it could be useful. I wonder, though; besides a spin effect (spinning every <x> marks, etc.), how else could they be used?

I guess in my mind, I imagine that the effects would be the discrete points used, and would just be dragged and snapped to the marks to get the timing required.


Use case: Minitree is part of Minitree Group and part of Red Group. Minitrees are currently in a chase for the chorus but at the same time you wish to fade all Red items up to 100% as you set up a red to green sweep in the three timing marks at end of chorus.
Which effect has priority? Will this even work? Actually doing it in the sequencer seems to work but how is the output handled?

They both work. They both generate discrete level commands, which are then combined at runtime to get the desired value. For simple setlevel commands, the default combination is just to take the higher value of all current commands.


expanding on KC's post about weighting effects across the yard by distance 20%,60%,20% i think was the examples.
Use case: Apply a sweep effect so blue washed down a megatree with 56 vertical pixels then across a yard with 12 rows of RGB elements and back up second tree with 56 vertical pixels, total rows tranversed 124, total groups 3. Sweep effect could be controlled by total rows, number of groups, fixed time steps or even timing marks as per previous cases.
This introduces the concept of weighting by rows/pixels or bulb counts.

I think I understand what you mean, however I would imagine that to be three individual chase effects, if it would be on three independent groups. Or, if it's something you're doing a lot, then you could put those three groups into another group (maybe called "front trees" or something), then apply a chase to that group. It would break down the sub-items, and apply it semi-intelligently. Hopefully. :-)


For very high channel counts the ability to hide nodes/groups/channels is highly desirable to keep the sequencing interface as clean as possible
In LSP this year I had 18 layers set up that are essentially groups in Vixen3, this would easily be more using the grouping concept.
Use Case: Megatree is made up of both RGB and Non RGB strings, hiding each would be desirable when working in each of the colour spaces.

I'm not sure I completely understand the problem. You could just make different groups to represent the different ways you want to work with the nodes. You could have a group for the megatree, with all of its subcomponents in order, then a group for just the RGB nodes of the megatree, and another group for the non-RGB nodes. Then you could apply effects to whichever of the groups you want to work with.


A major weakness is it's near complete lack of support for multithreading and multi-processors, in the days of 6 and 8 core processors this is a major issue. I didn't check if Vixen3 was using more that 1 core, i seriously hope it does.

Yep, plenty of threads. There's a good few in the execution engine alone, then a thread per output controller. There's more threads, just can't remember where at the moment.

I remember a few weeks ago I opened up the task manager, and my thread count for the vixen app was either just over or just under 30 or so.

aussiephil
12-11-2011, 11:11 PM
I'm not sure that I completely understand you; however, you are able to have nodes that exist only in groups, so you don't have to have them all at a root/base level. For example, I've got ~1200 channels, and I've only got about 15 or so groups at the base level: things like "Minitrees", "Arches", "Treeline", etc. Then in the "Minitrees" group I have ~20 more groups -- Minitree-1 through to Minitree-20 -- then each of those has an R, G and a B channel in it. So when sequencing or configuring anything, I pretty much never see each inidividual R, G or B node, as I'm always working at a group level, or an individual item level.

Thanks for your feedback and comments. Hopefully I've shed some light on some of the issues. If you find bugs, or have feature requests, feel free to make tickets for them! It's the best way we have to track development, and keep things moving.

Cheers!

Wow, thanks for the comprehensive reply, i'll limit my response to the above till i can play some more with the other bits.

Your explanation above makes sense and is how I would expect it to actually function so it may be a lack of understanding on how to create them this way. The experience last night was to create some nodes and then group those nodes, the individual nodes stayed visible as well as existing in the group, again expected but that raised the question about hiding nodes. The same seems to apply if your start simple and create the channels via the output controller generate channels options.

What i don't get then is how to do the following
Group - Megatrees
Group - Megatree1
Group - Megatree2
Groups - MT1 RGB Strings 1 to 12
for each string group
Groups - 112 RGB pixels
and i guess each pixel is then a Node

If a group has say the RGB property does each node also need it? also can a group have both RGB and nonRGB members? and how are things like colour fades handled?

Do we start at the top with the group and work down, or more logically start at the pixel and group up. Then repeat for MT2 and then and the groups for the White/Blue/Green LED strings on each megatree as well. So each Megatree actually has a RGB grouping and a Non-RGB Grouping

Now in the above use case the strings go up and back down next to the up string creating 2 x 56 pixel strings that require say a wipe from bottom to top to turn on 1 and 112 then 2 and 111 etc, if we think of the pixel megatree as a 24 x 56 matrix with pixels arrayed in a up then down order - the question becomes has this sort of thing been considered?

Back to the groups and nodes, i'll have a little play time tonight after showtime is finished and see if I can figure this out. I'll also log a import request and attach a spreadsheet, if my dotnet coding wasn't so rusty i'd have a crack at it myself :)

Think i'll also log a request to have a "colour" property for every node. This could be used at various grouping to apply global colour cross fades involving non RGB elements. example being were a megatree has individual coloured LED strings say Green Blue White along with RGB could have the green strings light up when RGB is set to Green at the megatree group level.

I've got to stop thinking about this, next years sequences are already forming in my head.

Cheers

aussiephil
12-12-2011, 12:01 AM
Hmm, that's an interesting idea; having marks being able to be used by effects. Breaks a bit of the logical separation we had, but it could be useful. I wonder, though; besides a spin effect (spinning every <x> marks, etc.), how else could they be used?

I guess in my mind, I imagine that the effects would be the discrete points used, and would just be dragged and snapped to the marks to get the timing required.

.

Spin effect, chase effect and any future effect that can be actually synced to the music would make use of it, in this fashion the effects could be intellegently linked to the beat/timings the end user wants to use, not a pure animated set of steps.

Think about a yet to be created colour change effect, the effect could have a property that lists each of the colours to be used as well as animated timings like the spin effect. The colour change effect could then be applied across say 15 timing marks and each timing mark causes a step in the colour property, this way you can have completely automated colour changes based on non-linear timings that you have set to the music.
Second case, think about the fast sections in wizards in winter, a lot of people use chases during the fast bits, how cool would it be to set your timing marks to each bass beat and have the chase synced perfectly even when the beat pauses like it does.
This then raises the idea of (already in LSP) of grouped timing marks, ie bass timings, vocal timings, chorus timings etc.

The ability of effects to use defined timing marks in an intelligent fashion will lift Vixen3 right above a pure animation tool. As effects already have properties such as frequency/steps etc it can't be too hard to get the number of timing marks set by the user and use those, the non-linear nature may require some overhead during the generation but hard to work out the impact without some understanding of the code, my mind says code it this way and that would be low overhead but no doubt it's not that simple. I'm figuring though that as we are now dealing in objects and object properties and methods then most things may be possible even if it's not in 3.0/3.1

Cheers

sallz0r
12-12-2011, 12:21 AM
Your explanation above makes sense and is how I would expect it to actually function so it may be a lack of understanding on how to create them this way. The experience last night was to create some nodes and then group those nodes, the individual nodes stayed visible as well as existing in the group, again expected but that raised the question about hiding nodes. The same seems to apply if your start simple and create the channels via the output controller generate channels options.

Sure, I'll admit the process isn't very intuitive. The problem is that there's no defined way to do it -- it's incredibly flexible, but that makes it difficult to initially understand. :-)

When I set up my controllers, I created the controller, gave it channels and a name, then generated the channels I needed. Then, in the node setup form, I had a huge list of auto-generated channels. So, I made some new nodes. Let's say the channels were for 20 RGB minitrees. I made 20 new nodes, and used the bulk rename to name them "MiniTree-1" through "MiniTree-20". Then, knowing which channels were supposed to map to which minitree, I selected three channels at a time, and dragged them into the correct group, repeating that for all 20 trees. So, I had 60 channels in 20 groups, but only the 20 groups were visible at the root level.

Then, that was also pretty annoying -- plus I want to apply some effects to all the minitrees, like a chase, etc. -- so I made ANOTHER node, called it "Minitrees", then dragged all 20 trees into that one group. That way, it's nicely packed away, and never worries me, unless I want to operate on a single tree, in which case I can open the group up.

However, then I realized that I have the 20 trees down either side of the pathway -- so sometimes I want to work with only the left side, or only the right side. So, I make some MORE nodes -- Minitrees-Left and Minitrees-Right -- then find the appropriate ones (eg. 1 -> 10 for the left), select them, and CTRL-drag to the new node. (This copies instead of moves). Same for the right. Now I have the same nodes in multiple different places. They're the same *actual* nodes -- there's only one "Minitree-1" -- but if you click on it, it says on the RHS that it's part of 2 different groups: "Minitrees", and "Minitrees-Left".

Hopefully that makes sense?



What i don't get then is how to do the following
Group - Megatrees
Group - Megatree1
Group - Megatree2
Groups - MT1 RGB Strings 1 to 12
for each string group
Groups - 112 RGB pixels
and i guess each pixel is then a Node


I'm not sure I understand your groupings..... having said that, hopefully the explanation above sheds some light.



If a group has say the RGB property does each node also need it? also can a group have both RGB and nonRGB members? and how are things like colour fades handled?


Aah, the RGB property. That one is probably a bit misleading and confusing.

The RGB property is more intended to be used at an individual item level; the property says "this node that I am applied to can be lit up as an RGB item. Don't bother going deeper and looking at my child nodes, you can render a color/level directly on me."

This is because there's (at least) two different ways to do RGB, both of which are worked with completely differently: one is to have discrete R, G and B channels for each color, and have Vixen do the breakdown of the requested color to the specified color component nodes. The other is to assume that the output controller has knowledge of color, and can deal with a color command and apply it correctly to the requested outputs -- so in this case, Vixen doesn't do any of the color handling/breakdown. It just says "OK, channel 'Megatree-4', please set your color to #FF8020", and expects the controller module to be able to handle that.

So that's why that configuration option for the RGB property is there.

By default, the property -- when first applied to a group -- will see if it has 3 children in the group. If so, it assumes they are R, G and B in that order, and configures itself to be an RGB node on those three children. If it doesn't have three children, it assumes it must be the 'smart' controller type of RGB.

So, for my example above -- 60 channels as minitrees, as 20 groups of 3 -- I could just add the RGB property to each minitree. (if you right-click on a node, you see there's options that could be used to quickly copy-paste the properties).



Do we start at the top with the group and work down, or more logically start at the pixel and group up. Then repeat for MT2 and then and the groups for the White/Blue/Green LED strings on each megatree as well. So each Megatree actually has a RGB grouping and a Non-RGB Grouping


Either.... or a bit of both, I guess. It's definitely going to be easier to work up for the very low level, generating the channels from the controller form, simply because otherwise you have to manually patch all the logical channels to the appropriate controller. That would be..... tedious. :-)

At the same time, it's also sometimes easier to make the logical group nodes first -- Minitrees, Megatree, Arches, etc. -- then work down, dragging the appropriate nodes into each group.




Now in the above use case the strings go up and back down next to the up string creating 2 x 56 pixel strings that require say a wipe from bottom to top to turn on 1 and 112 then 2 and 111 etc, if we think of the pixel megatree as a 24 x 56 matrix with pixels arrayed in a up then down order - the question becomes has this sort of thing been considered?


I'm not sure I fully understand your setup, but yes, the general concept has been considered. If each pixel is individually controllable, it sounds like a perfect candidate for a grid configuration/setup.

By all means, make a feature request ticket for that, and put more information into it about what you want to do, or how you imagine it would work. So far, the software is mostly the framework, with only examples of modules, properties, effects, etc. I've only written the modules that I imagine myself needing for my display, since I know how I want to use them. But for other things -- pixel displays, mixing RGB/non-RGB lights, RGB+W lights -- I've considered them, but decided we would need community feedback and discussion to figure out how people want to use it. No point writing something if it's not what most people want. :-)



Think i'll also log a request to have a "colour" property for every node. This could be used at various grouping to apply global colour cross fades involving non RGB elements. example being were a megatree has individual coloured LED strings say Green Blue White along with RGB could have the green strings light up when RGB is set to Green at the megatree group level.

Yeah, that's one that's definitely needed, but wasn't sure on how people wanted to use it. Does it use the color part, and try and only turn on for the appropriate color of an effect? Does it ignore the color part, and just act as a simple level controlled light? (ie. the color is only for the software visualization and preview?).... etc.

But by all means, ticket it; it's good to have the discussion for a particular feature tied into discrete chunks, so we can assess things properly. :-)

aussiephil
12-12-2011, 02:13 AM
Sure, I'll admit the process isn't very intuitive. The problem is that there's no defined way to do it -- it's incredibly flexible, but that makes it difficult to initially understand. :-)

Hopefully that makes sense?
I'm not sure I understand your groupings..... having said that, hopefully the explanation above sheds some light.

Either.... or a bit of both, I guess. It's definitely going to be easier to work up for the very low level, generating the channels from the controller form, simply because otherwise you have to manually patch all the logical channels to the appropriate controller. That would be..... tedious. :-)

I'm not sure I fully understand your setup, but yes, the general concept has been considered. If each pixel is individually controllable, it sounds like a perfect candidate for a grid configuration/setup.

:-)

Yes the explanation helped lots and i will really give it a work out.

Doing the generation and patching for 2500 pixel nodes will be tedious anyway :) hence my thoughts around bulk imports.

One thing that jumps to mind was the goal to separate the logical channels/nodes/groups in the sequencer from the physical output channels to allow easy changes year to year with most people retaining whole elements but not always the same output channels. If your calling it tedious to manage after the fact at creation time then it will be tedious to change each season.
2500 pixels means 7500 channels generated from the controller form each dragged into a 3ch Pixel then grouped into a string etc. I'd love to see the ability to say, here's an element it consists of x RGB elements and then have those nodes created under the original element.
Worded another way, please create a node for this 112 pixel string with each pixel requiring 3 channels. The system could then create all 336 channel nodes, the 112 pixel nodes and the pixel group node.

I don't want to cause to much typing and questions and I do hope some of this is helpful from someone who has a technical complex display, so i should go away and play.

This is highly exciting and as i have said the move towards objects and object based attributes is extremely promising.

Cheers

CaptKirk
12-12-2011, 01:21 PM
It's close. I need to do some device testing on it, then it should be ready.

Erik

If you need a tester, I have both an RPM and "another" DIY dongle I can try out.
Kirk

Wombat
12-12-2011, 10:07 PM
I like AussiePhils ideas as well I would like to put in some of my thoughts. Im sorry if my ideas are similar to the others but hopefully we can find some common ideas.

As alot of us are moving towards large RGB pixel networks there needs to be tools available in the kit to visualise and manipulate the pixels on an overall overlay picture.

I find as others also do that the initial setup of the channels and strings within Vixen are the hardest and most time consuming part of the display sequencing. Apart from the actual sequencing :)

Anything that can be done to aid in setting this up and doing sequencing easier would be greatly appreciated. Here is some of my rough thoughts.

1) like the ability to place all of the pixels and objects on a map showing their relative positions and (layed out like a x,y,z matrix grid) and then to be able to do things like sweep from left-right up-down circular (whatever effect) to that grid. for instance to do things like Holman's sequences where he sweeps from left to right across the whole house to change colours. when the sweep line gets to an object in the grid it changes colour. Then you could do transitions using Video etc to do effects over your whole display. With RGB displays this could be rainbow effects across the whole display or individual objects etc.

the key is to use the display preview as a virtual screen. wherever you place the objects in the grid (on your background image) it gets an X,Y and Z co-ordinate on the map. then you could manipulate the display just by doing sweeps etc across the display.

I hope im making sense.

2) Definitely need to be able to say I have a string of 42 pixels in RGB format starting at channel 513 and it gets mapped into the display. by placing cursor where you want to start and letting go where you want to stop. The old way of having to map each channel individually to the overlay is extremely unproductive. it was fine when we had 200 lights on the same channel but no longer is this the case with RGB .

Also a freehand drawing is needed for shapes etc.
These would be objects you can drop on the display that can be shared with others.

3) an object creator would be a good start the ability to draw a X pixel string on the grid and then move around individual pixels into position. (like a star or shape etc) would be beneficial. once the object has been created and saved this could be used over and over on the grid (or swapped between others etc as XML files?)

4) like what Phil said the ability to move objects around on the display, change their channels and have all of the data automatically move with it or in the above examples remap to the new position on the display (for sweeps,video overlays, transitions etc)

5) ability to apply transitions etc to objects i.e minitrees,megatrees etc

theres plenty more I just dont have time to think of them now (im trying to sequence)

Regards
Wombat

sallz0r
12-12-2011, 10:55 PM
As alot of us are moving towards large RGB pixel networks there needs to be tools available in the kit to visualise and manipulate the pixels on an overall overlay picture.

From what I can tell, most of your notes are for improvements to the display preview and how to easily configure it to reflect what the display looks like, correct? If so, then no worries; I know there's been discussion of many extra features with the preview and the way to set it up, and there's more to go into it. We just had to stop the feature creep, and get something out so we could get feedback from the community. :-)


5) ability to apply transitions etc to objects i.e minitrees,megatrees etc

What do you mean by transition? I'm guessing it's an LSP term; I haven't used it at all, so I'm not familiar with it?

aussiephil
12-12-2011, 11:59 PM
What do you mean by transition? I'm guessing it's an LSP term; I haven't used it at all, so I'm not familiar with it?

Yep - transitions is a LSP term and is the ability to apply short video effects across groups of channels, you specify the number of frames to generate and LSP then gets frames from the video and maps them into your display.
Having done the same sort of thing manually for my Vixen sequences the last two years it's a great way to apply complex effects, one effect I likely overuse but people love it is what looks like snow falling down the megatrees as white dots. This is a video sequence of animated snowflakes!

Sallz0r - I played a fair bit last night and have got a handle on the whole nodes/groups structure, it's like I expected it to be with some idiosyncratic methods that make it seem inconsistant, so I will feed the info back when I get it straight on how to write it up.
My comments stand though on the desperate need to have some form of import for large counts, not only to cover the creation but the mapping from the nodes to the physical controllers.
How about the ability to CLONE a Node. if no channel mapping just clone the node and all nodes under it without further questions, if with channels mapped then maybe ask if channels should stay on same controller and just increment the physical mapping or drop the current mapping or map to different controller.
This would allow creation of default nodes that could then be cloned for easy creation. This would further leverage the object functionality.
Just creating 336 nodes to map to physical channels and then dragging and dropping them into the Pixel nodes was tedious and not something people with RGB pixels will be even vaguely interested in doing for more than a few hundred pixels.

Quick question as even re-reading most of the info I can't see if it's been answered - Can an effect be applied across multiple rows when dragged and dropped?

Cheers

sallz0r
12-13-2011, 12:12 AM
Yep - transitions is a LSP term and is the ability to apply short video effects across groups of channels, you specify the number of frames to generate and LSP then gets frames from the video and maps them into your display.
Having done the same sort of thing manually for my Vixen sequences the last two years it's a great way to apply complex effects, one effect I likely overuse but people love it is what looks like snow falling down the megatrees as white dots. This is a video sequence of animated snowflakes!

Gotcha. That's the sort of thing I would imagine could be handled pretty well by an effect to play a video or a picture, onto a group which is configured as a 'display' or a 'grid'. (ie. rows/columns mapping). Those modules don't exist yet, but the idea is there, and I would expect it would work well.


My comments stand though on the desperate need to have some form of import for large counts, not only to cover the creation but the mapping from the nodes to the physical controllers.
How about the ability to CLONE a Node. if no channel mapping just clone the node and all nodes under it without further questions, if with channels mapped then maybe ask if channels should stay on same controller and just increment the physical mapping or drop the current mapping or map to different controller.
This would allow creation of default nodes that could then be cloned for easy creation. This would further leverage the object functionality.
Just creating 336 nodes to map to physical channels and then dragging and dropping them into the Pixel nodes was tedious and not something people with RGB pixels will be even vaguely interested in doing for more than a few hundred pixels.

Yeah, I understand that part of it. The problem is reducing it to a problem which is more generically solvable, or something that isn't specific to some use cases. That's why we haven't put anything much in. If we can get more feedback from users about how they want to use it, though, and get a nice range of the way people would be doing things, we could work from there.


Quick question as even re-reading most of the info I can't see if it's been answered - Can an effect be applied across multiple rows when dragged and dropped?

Yes and no. An effect *can* operate on multiple nodes -- in fact, when rendering things like chases, it just iterates through child nodes until it hits something that is 'renderable' (eg. an RGB node, or a node without children), and applies to them in order.

However, the UI doesn't currently support having an effect (a 'block' on the grid) on more than a single row. It's quite a difficult problem to deal with, in all honesty, and opens up a fair few cans of worms. That's why, for now, the solution is just to make groups of the targets you're after, then apply effects to the specific groups. (or, the individual nodes inside the group, if that's easier for the once-off case).

aussiephil
12-13-2011, 12:59 AM
Gotcha. That's the sort of thing I would imagine could be handled pretty well by an effect to play a video or a picture, onto a group which is configured as a 'display' or a 'grid'. (ie. rows/columns mapping). Those modules don't exist yet, but the idea is there, and I would expect it would work well.



OK Cool
Thought, element positioning on the xy grip of the display preview screen could provide a default matrix grid for effects to get element position data to intelligently do whole of display sweeps and chases. The xy coords could be attributes for each node :)

Should i stop talking now?




Yeah, I understand that part of it. The problem is reducing it to a problem which is more generically solvable, or something that isn't specific to some use cases. That's why we haven't put anything much in. If we can get more feedback from users about how they want to use it, though, and get a nice range of the way people would be doing things, we could work from there.


OK, I'll add both the clone and import as requests, I have tried to treat the requirement generically even if based in my usage. The proliferation of RGB pixels is going to put some mandatory requirements on Vixen3 to be able to easily deal with very high channel counts (VHCC) from both a configuration and sequencing viewpoint. Seems like the sequencing is in hand, just the admin side needs to improve. (i know it's beta, and the chance to provide feedback is welcome)
VHCC displays will be the norm very soon and there's some very good experience already out in the community running those displays.
If it wasn't for the GUID's i'd just write a quick vb script to manipulate the XML data directly, but would rather see the requirements built into the application.




Yes and no. An effect *can* operate on multiple nodes -- in fact, when rendering things like chases, it just iterates through child nodes until it hits something that is 'renderable' (eg. an RGB node, or a node without children), and applies to them in order.

However, the UI doesn't currently support having an effect (a 'block' on the grid) on more than a single row. It's quite a difficult problem to deal with, in all honesty, and opens up a fair few cans of worms. That's why, for now, the solution is just to make groups of the targets you're after, then apply effects to the specific groups. (or, the individual nodes inside the group, if that's easier for the once-off case).

OK - let's not open the can, working with groups fits the object framework and is a great direction.

It was interesting that LSP this year drove me to actually map out and document my entire display into it's groups/layers/colours/layout whereas previous years in Vixen i just keep it all visualised in the head and flew it blind with no previews.
Vixen3 will have the same effect to make even small display people document and group the display elements and this is not a bad thing.

Livermore-Dad
12-13-2011, 01:23 AM
I'm not going to add much here, but wondered if there are any sample video's of how basic stuff is done in 3.0. I thought there was but couldn't find it. I tried on my own with no guidance and got a tad confused.

Tory

sallz0r
12-13-2011, 08:37 PM
I'm not going to add much here, but wondered if there are any sample video's of how basic stuff is done in 3.0. I thought there was but couldn't find it. I tried on my own with no guidance and got a tad confused.

Unfortunately, there's not yet. I had planned to write up information to try and get people started, but unfortunately the pressures of my own display mounted and I've had to focus more on that for the last month or so.

So, unfortunately, at the moment it's a bit of a free-for-all. In some ways, that could be a sort-of-good thing -- it lets us know how intuitive and easy-to-use the software is. At the moment, I'm guessing not very. ;-)

Hopefully in the new year we can get more information out: for now, the best option would be to read through this thread, as there's lots of tidbits in here, and also the other intro threads for the concepts in 3.x. If you have specific questions about things after that, by all means, ask them and we can answer them.

aussiephil
12-14-2011, 06:33 AM
I'm not going to add much here, but wondered if there are any sample video's of how basic stuff is done in 3.0. I thought there was but couldn't find it. I tried on my own with no guidance and got a tad confused.

Tory

Seeing as I was a little bored this afternoon, (excited about Vixen3 actually) thought I might put together a little 20 minute "how to" on setting up modes/groups, controller channels and a quick look at the actual sequencer.
Hopefully this might be of use, as well a spark some more people to have a play.

The video can be found below
http://vimeo.com/33649876

If any of mods feel this should be split off to it's own thread please do so. If people would like I can do more of these as I learn more and modules evolve.

Cheers

TimW
12-14-2011, 09:33 AM
Thanks Phil. Very clear display of the potential. (BTW I'm still using your conversion routines on 2.1.4 this year!)

Love the separation from physical controllers and the grouping in general.

I'm also with you completely on the idea of using inserted timing lines as 'waypoints' to sync effects. That would be awesome.

Tim

sallz0r
12-14-2011, 10:23 AM
Seeing as I was a little bored this afternoon, (excited about Vixen3 actually) thought I might put together a little 20 minute "how to" on setting up modes/groups, controller channels and a quick look at the actual sequencer.
Hopefully this might be of use, as well a spark some more people to have a play.

The video can be found below
http://vimeo.com/33649876

Hey, fantastic! Thanks for that!

I'm just watching it now, and have a few comments to make as I watch....

1) You create the second node with a right-click, and it sounds like you're doing that to get it in the group -- you say "we do it this way to create the new node underneath this one". I realize that we may have never mentioned it -- everything should be click-and-drag to reorder, or move within groups, etc. So you could have created the node with the button on the RHS, which would have put it at the root level of the tree..... but then click-dragged it into the top node to add it to that group.

2) Yeah, the copy node isn't clearly explained. I should probably make another option that is "duplicate node" or something like that. "Copy Node" actually makes another reference to that EXACT node somewhere else: so you could have "Tree 5" in group "Trees", then you could copy it to another group called "Bushes on Left" or something. That way, the EXACT same node is in two different groups. If you change the name of one, the other changes. If you change children, it affects both of them, etc.

Would a "duplicate node" option be useful? What would it do....... I guess duplicate the node, but as a DIFFERENT node, ie. no relation to the original. Like you would expect a copy/paste of a file to work, or text to work. ...... Hmm, actually, that might not work nicely: what do you do about child nodes? Duplicate them as well, or 'link' references?........ hmm. What do people think? Would that be useful? Or just confusing? How would you expect it to work?

3) oh, ignore comment (1). I see you do some dragging later on.

4) When you created the group from selected nodes, you made a comment about the fact that it basically copied them, and thus you needed to delete them from the original location. Do people find that annoying? When making a group from selected nodes, should we MOVE them to the new group, instead of copying them? I could see use cases for both. How about a message box, asking what you want to do each time? Actually, that's a crappy idea, that would get annoying.

5) It's really fascinating to see how other people use the channel/group setup -- since I've obviously got one way in my head, it's cool to see how other people think about things, group them, and the process you go through. :-) One comment to make about the way you used the nodes auto-created with patches, though: well, obviously you can set it up however you like. I've found though, as a general rule of thumb -- it helps if you make sure that ALL your node names in the tree on the left hand side represent some sort of logical group or physical object. For example, groups called "minitrees", or "red lights", or all those sort of things -- great! But when you made patched channel nodes, they were all called "Renard-x", and then you dragged them into the predefined nodes. Personally, I would have used those nodes directly -- ie. renamed "Renard-1" to be "Minitree-1", then put it in the appropriate group. Then renamed "Renard-2" to be "Minitree-2", and also added a new patch to renard output 3 (since you say you use 2 channels for the blue ones).

It's quite a moot point in this case: I'm only mentioning it because I found when testing, desgining, etc., that I found it very helpful to maintain a separation in my mind between the 'high level' groups and channels, and the real, physical controller outputs and patches to them. The main idea is to only use the channels/groups to describe your display setup: what props you have, what groups they're in, etc. There shouldn't be any nodes or groups that tie you specifically to controllers.

Having said that, it doesn't really matter how anyone uses it; i's quite open for that reason. That's just something I've found helps me. :-)

6) Yeah, the default settings for some effects (pulses, chases) might need saner defaults. If anyone has comments about what would make sense for saner defaults, let us know.

7) You make a comment about the color gradient box -- saying "I want some feedback from the devlopers on this" -- but don't go into it. Any comments/feedback?

Awww, thank you for your kind comments, as well. I'm glad people can see some of the positive changes that are coming, and some of the potential. :-)

Thanks so much for making the video! It's great to see the community getting behind it, and helping out with things like that. *grin*

(BTW, what software do you use to do the screen capture? I'll have to figure something like that out to do tutorials....)

budude
12-14-2011, 12:39 PM
First - good to see you back in action Phil - your infinite wisdom is always appreciated and second - thanks for the video - that was quite helpful and it made the light bulbs go on for me now!

smartalec
12-14-2011, 02:09 PM
Seeing as I was a little bored this afternoon, (excited about Vixen3 actually) thought I might put together a little 20 minute "how to" on setting up modes/groups, controller channels and a quick look at the actual sequencer.
Hopefully this might be of use, as well a spark some more people to have a play.

The video can be found below
http://vimeo.com/33649876

If any of mods feel this should be split off to it's own thread please do so. If people would like I can do more of these as I learn more and modules evolve.

Cheers

Thanks For a Great vixen video Phil,
I have placed a link over at ACL if you dont mind,
hope your display turned out the way you wanted it

corytcline
12-14-2011, 02:10 PM
very nice on the video, it answered a lot of my questions

corytcline
12-14-2011, 02:19 PM
if I download the .net framework 4 to my show computer will it mess up the framework vixen 2.1 required?

bud29
12-14-2011, 02:38 PM
Great video Phil. Haven't even been thinking about Vixen 3 yet as I've been so busy getting the display working. Definitely gives me something to look forward to for Christmas 2012.

Rob

Matt_Edwards
12-14-2011, 03:38 PM
Wow factor is high. I have played with 3.0 but Phil, my hat is off to you sir. @ 4:00am this morning, your vid made it all make a whole more sense!

aussiephil
12-14-2011, 06:52 PM
Hey, fantastic! Thanks for that!

I'm just watching it now, and have a few comments to make as I watch....

1) You create the second node with a right-click, and it sounds like you're doing that to get it in the group -- you say "we do it this way to create the new node underneath this one". I realize that we may have never mentioned it -- everything should be click-and-drag to reorder, or move within groups, etc. So you could have created the node with the button on the RHS, which would have put it at the root level of the tree..... but then click-dragged it into the top node to add it to that group.


Right click, new node is a great way to create nodes under existing groups and saves a drag operation after the fact, glad to see the good use of the context menu



2) Yeah, the copy node isn't clearly explained. I should probably make another option that is "duplicate node" or something like that. "Copy Node" actually makes another reference to that EXACT node somewhere else: so you could have "Tree 5" in group "Trees", then you could copy it to another group called "Bushes on Left" or something. That way, the EXACT same node is in two different groups. If you change the name of one, the other changes. If you change children, it affects both of them, etc.

Would a "duplicate node" option be useful? What would it do....... I guess duplicate the node, but as a DIFFERENT node, ie. no relation to the original. Like you would expect a copy/paste of a file to work, or text to work. ...... Hmm, actually, that might not work nicely: what do you do about child nodes? Duplicate them as well, or 'link' references?........ hmm. What do people think? Would that be useful? Or just confusing? How would you expect it to work?


"Clone to new node" or duplicate would be very useful, if no child nodes it should immediately create a new node with the suffix number incremented by one or if no suffix then add -x just like the rename dialog does if you rename to the same name as another node.
If there are child nodes then pop a dialog asking should all the nodes be cloned with the following options, including all properties and including channel mappings or just copy all children.
The first one above, a straight clone, i already have a vbscript to directly write the XML data for all my Pixel nodes in my display, but would love to see it in the app.





3) oh, ignore comment (1). I see you do some dragging later on.

:)



4) When you created the group from selected nodes, you made a comment about the fact that it basically copied them, and thus you needed to delete them from the original location. Do people find that annoying? When making a group from selected nodes, should we MOVE them to the new group, instead of copying them? I could see use cases for both. How about a message box, asking what you want to do each time? Actually, that's a crappy idea, that would get annoying.


Yeah, message box would be annoying, just make two context menu options, "Move nodes to new Group" and "Copy Nodes to new Group"



5) It's really fascinating to see how other people use the channel/group setup -- since I've obviously got one way in my head, it's cool to see how other people think about things, group them, and the process you go through. :-) One comment to make about the way you used the nodes auto-created with patches, though: well, obviously you can set it up however you like. I've found though, as a general rule of thumb -- it helps if you make sure that ALL your node names in the tree on the left hand side represent some sort of logical group or physical object. For example, groups called "minitrees", or "red lights", or all those sort of things -- great! But when you made patched channel nodes, they were all called "Renard-x", and then you dragged them into the predefined nodes. Personally, I would have used those nodes directly -- ie. renamed "Renard-1" to be "Minitree-1", then put it in the appropriate group. Then renamed "Renard-2" to be "Minitree-2", and also added a new patch to renard output 3 (since you say you use 2 channels for the blue ones).

It's quite a moot point in this case: I'm only mentioning it because I found when testing, desgining, etc., that I found it very helpful to maintain a separation in my mind between the 'high level' groups and channels, and the real, physical controller outputs and patches to them. The main idea is to only use the channels/groups to describe your display setup: what props you have, what groups they're in, etc. There shouldn't be any nodes or groups that tie you specifically to controllers.

I'm actually struggling with the statement "There shouldn't be any nodes or groups that tie you specifically to controllers" as you must eventually map a node to an output channel and by far the easiest way is to create the channels as nodes and let the system automap them, renaming them after that is (IMO) a bit of a waste of time. Now if we had a Patch Management Window :)
Oh by the way the reason the blue trees require to individual channel nodes is because they effectively have 2 independent strings that need individual control




Having said that, it doesn't really matter how anyone uses it; i's quite open for that reason. That's just something I've found helps me. :-)

:) agreed, ditto for me, and i'm sure others will come up with more.





6) Yeah, the default settings for some effects (pulses, chases) might need saner defaults. If anyone has comments about what would make sense for saner defaults, let us know.



Actually i think the defaults are fine, you have to start somewhere, my suggestion though is to use the power of XML. Add a tick box to the config screens that is "save as defaults" and have each effect store both the original system defaults and the user defaults in a XML file, This XML file could also store last x used gradients etc.





7) You make a comment about the color gradient box -- saying "I want some feedback from the devlopers on this" -- but don't go into it. Any comments/feedback?


Oops never got back to that, sorry, at the moment the usage of the gradient box to me is still a mystery, if i select a colour at 0% say red the box shows red, then drag the slider to 100% and select blue the box changes to blue, whereas i would expect it to show a red to blue gradient.




Awww, thank you for your kind comments, as well. I'm glad people can see some of the positive changes that are coming, and some of the potential. :-)

Thanks so much for making the video! It's great to see the community getting behind it, and helping out with things like that. *grin*

(BTW, what software do you use to do the screen capture? I'll have to figure something like that out to do tutorials....)

No problem doing the video, it's my favourite method to also capture bugs and user interface issues, so watch out as we dive in further :)

The software i'm using is Camtasia and it also has some great autozoom/focus functionality that for some reason wasn't working in that clip.

aussiephil
12-14-2011, 06:56 PM
if I download the .net framework 4 to my show computer will it mess up the framework vixen 2.1 required?

Can't directly comment on Vixen2.1 as i've only used 2.5 for the last two years, but 2.5.08 runs fine with dotnet4 installed. We went through this big time at work and have yet to see an older dotnet app be broken by v4.

aussiephil
12-14-2011, 07:13 PM
Thanks Phil. Very clear display of the potential. (BTW I'm still using your conversion routines on 2.1.4 this year!)

Love the separation from physical controllers and the grouping in general.

I'm also with you completely on the idea of using inserted timing lines as 'waypoints' to sync effects. That would be awesome.

Tim

Glad to see others still getting use from the conversion scripts, made heavy use of them again this year myself.
I'm so sold on timing markers and having effects use them i have been reading up on stuff like "beat slicing and tempo mapping" to see if there is anything already that will drop beat/tempo info out to a file as timecode data, the timecode data could then be used by effects.
Actually having typed that and thinking that video support is on the "to do" list then maybe building into the basic blocks support for timecode data would be beneficial.


First - good to see you back in action Phil - your infinite wisdom is always appreciated and second - thanks for the video - that was quite helpful and it made the light bulbs go on for me now!
Brian, "infinite wisdom" not sure the head can handle that :)


very nice on the video, it answered a lot of my questions
Thanks


Great video Phil. Haven't even been thinking about Vixen 3 yet as I've been so busy getting the display working. Definitely gives me something to look forward to for Christmas 2012.

Rob
Thanks


Wow factor is high. I have played with 3.0 but Phil, my hat is off to you sir. @ 4:00am this morning, your vid made it all make a whole more sense!
Matt, Thanks :) for a change at 4am i was sound asleep

Alec: Yes please links over at ACL, the reason the posts are here is this is the official Vixen support forum, all my friends and members at ACL should have a look at this, Vixen3 may just change the game again. The display is up and comments and smiles make it worthwhile even though the animation this year is not what i was aiming for.

Desperately waiting now for both DMX and E131 plugins so we can really start testing, even a DMX plugin would give me something to play with as i only have DMX based hardware.

bnradams
12-14-2011, 07:55 PM
Awesome video Phil.

I've been playing with 3.0 and love the ease of applying effects and the ability to have a 'logical' representation of output to sequence with. I havent actually tried to drive any physical lights yet (havent upgraded my show computer with .net 4).

One question I have is how 3.0 will handel 'overlapping' effects?, ie if I have a layers of nodes (mega tree node - red lights node - individual nodes) and apply one effect to the highest level (spin on the mega tree node) and a second effect during the same time frame to a lower level node (pulse all red nodes).
Will the effects have an additive effect?
Will the highest level effect overide the lower level effects?
Will the effect at the lowest level (directly applied to output node) override all others?
Can this be set (simallar to V2.x arithmatic paste), able to set additive, override, max value etc...?

sallz0r
12-14-2011, 08:37 PM
One question I have is how 3.0 will handel 'overlapping' effects?, ie if I have a layers of nodes (mega tree node - red lights node - individual nodes) and apply one effect to the highest level (spin on the mega tree node) and a second effect during the same time frame to a lower level node (pulse all red nodes).
Will the effects have an additive effect?

Yes. They're intelligently combined to give something that 'makes sense'. For the case of lighting commands (eg. set level to <x> commands), the highest value is what's output.


Will the highest level effect overide the lower level effects?

Depends what you mean by 'level' -- if you mean "light intensity value", then yes. If you mean "group level within setup", then no.


Will the effect at the lowest level (directly applied to output node) override all others?

No. Everything for a particular output is combined to give a single current state. In essence, the higher-level groups only exist to provide convenient collections to which you can apply effects, and have them automatically mapped down to the lowest level nodes/outputs.


Can this be set (simallar to V2.x arithmatic paste), able to set additive, override, max value etc...?

Hmm, not really; it's not really designed like that. Those options were only really available because in 2.x, the user needed to do the legwork to make the raw low-level values, breaking everything down into the discrete commands needed (hence the grid). However, in 3.x, that's not needed anymore: the effects are there to take care of it at a higher conceptual level.

What are you trying to do that you need this functionality for? If there's something else you're trying to do and can't, then we can address that issue separately. :-)

aussiephil
12-14-2011, 09:15 PM
Sallz0r : Think I have an example that is actually something I believe is quite commonly used.

Example Spin Megatree based on Strings whilst at the same time fading the entire display down to zero, usually at the end of a song. This works a charm under V2 by doing a paste of a ramp down over the top of the spin.
Under Vixen3 with it taking highest value by default this would not be possible.

Here's how i think it could be implemented and it's just a variation on ACN protocol rules.
Give each group/node point (object) a property value for "Effect Weighting" and default this to 100 for each node. Then someone could set say "all lights" to have a weighting of 110 and thus overriding other lower value groups.
Business rulles for effects become, if weighting same then take highest value otherwise take highest weighted value.
or
Alternatively or also as, the same property could be applied to effects, thus effects of equal weight combine, whilst higher overides.

If the future you could also apply this as an effect weighting curve and open up possibilities in effects combinations that are unlimited.

I really really need to stop thinking about this............ :)

Blackbeard
12-14-2011, 09:19 PM
My computer is showing the following in my control panel:

Microsoft .Net Framework 4 Client Profile
Microsoft .Net Framework 4 Extended

This is a Windows 7 Pro Laptop. Do I still need to install some form of .Net 4 or is this good enough to run Vixen 3?

CaptKirk
12-14-2011, 09:21 PM
My head is doing a spin with a fade to 0 as we speak after thinking about your suggestion!! But is makes sense to me (whatever that is worth).:pinch:

sallz0r
12-14-2011, 09:22 PM
My computer is showing the following in my control panel:

Microsoft .Net Framework 4 Client Profile
Microsoft .Net Framework 4 Extended

This is a Windows 7 Pro Laptop. Do I still need to install some form of .Net 4 or is this good enough to run Vixen 3?

I'm pretty sure that should be fine. Try it and see - worst case, it just complains about something. :-)

sallz0r
12-14-2011, 09:27 PM
Sallz0r : Think I have an example that is actually something I believe is quite commonly used.

Example Spin Megatree based on Strings whilst at the same time fading the entire display down to zero, usually at the end of a song. This works a charm under V2 by doing a paste of a ramp down over the top of the spin.
Under Vixen3 with it taking highest value by default this would not be possible.

Funny you should mention it. That's actually something we've been discussing, as it's something that's lacking. There's been a few suggestions thrown around, but we're trying to figure out a solution that's suitably generic.

intwoit2002
12-14-2011, 09:50 PM
I am having a problem trying to run Vixen 3.0 beta. I have installed .net 4 and .netx (for vixen 2.1), can they coexist? I get an error message when trying to open new sequence, "instance of object not found"?

I have vixen installed in programs/vixenbeta/vixen.

Running WIN7 32 bit.

I downloded vixen again and uninstalled old v3.0 beta, and installed new, now nothing works, says vixen opened but no splash screen.

I am very confused right now, and thougths would be appreciated.

Thanks,
Al

sallz0r
12-14-2011, 09:59 PM
I am having a problem trying to run Vixen 3.0 beta. I have installed .net 4 and .netx (for vixen 2.1), can they coexist? I get an error message when trying to open new sequence, "instance of object not found"?

I have vixen installed in programs/vixenbeta/vixen.

I downloded vixen again and uninstalled old v3.0 beta, and installed new, now nothing works, says vixen opened but no splash screen.

I'm not sure what '.netx' is, I haven't heard of it before. You should be able to have just .NET 4, Vixen 2.x should work fine with that I believe. (.NET is pretty backwards compatable).

The only thing I can think of -- I know Vixen 3.x stores it's data in your Documents/Vixen. Do you have stuff in there already? Is there anything interesting in the logs in the Logs/ directory?

intwoit2002
12-14-2011, 10:08 PM
Thanks I will try that i meant to say .net 4 and .net 3 sorry for the confusion. Should I uninstall .net 3?

Thanks,
Al

intwoit2002
12-14-2011, 10:11 PM
I did check log error messages 4 from renard com issues.

aussiephil
12-14-2011, 10:17 PM
Al

The 2.1 experts can chip in but for the whole 2.2cents (GST inc) it's worth my experience with 2.5.0.8 has been to do nothing special under Win7 as far as dotNet, just whatever is installed, however I never put Vixen under the program folder, to many silly permissions on that folder, just unzip to a Vixen2x folder on C and run from there. For ages i ran 2.1 from a USB drive
So for me 2.5.0.8 runs from c:\vixen25
Vixen3 is running from K:\vixen30beta

They both however write user data folders under c:\users\<yourname>\documents\vixen fortunately the folder names don't clash from what i can tell. Thought about submitting this as a bug but haven't yet.

Cheers

intwoit2002
12-14-2011, 10:20 PM
Thanks will try that now.
Best

intwoit2002
12-14-2011, 10:32 PM
Here is the errorSee the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object.
at VixenModules.Editor.TimedSequenceEditor.TimedSeque nceEditorForm.RestrictVisibleTimeToSequenceLength( )
at VixenModules.Editor.TimedSequenceEditor.TimedSeque nceEditorForm.TimedSequenceEditorForm_Resize(Objec t sender, EventArgs e)
at System.Windows.Forms.Control.OnResize(EventArgs e)
at System.Windows.Forms.Form.OnResize(EventArgs e)
at System.Windows.Forms.Control.OnSizeChanged(EventAr gs e)
at System.Windows.Forms.Control.UpdateBounds(Int32 x, Int32 y, Int32 width, Int32 height, Int32 clientWidth, Int32 clientHeight)
at System.Windows.Forms.Control.UpdateBounds(Int32 x, Int32 y, Int32 width, Int32 height)
at System.Windows.Forms.Control.SetBoundsCore(Int32 x, Int32 y, Int32 width, Int32 height, BoundsSpecified specified) message I get I am lost.

sallz0r
12-14-2011, 10:43 PM
I'm really not too sure, sorry. That sounds very bizarre..... Oh, hmm, hang on -- have you set up any channels or nodes yet? I *thought* it worked without any, but can't remember when I tried it last.

Otherwise, I'll have to have a look at home tonight. I've not seen that before.

intwoit2002
12-14-2011, 11:08 PM
Thanks appreciate any help.

corytcline
12-15-2011, 04:02 PM
I have been playing with the new features I think they are great.
How would you set up a chase on a few channels that are not grouped together?

ErnieHorning
12-15-2011, 04:27 PM
How would you set up a chase on a few channels that are not grouped together?The little bit of play with this say’s that you can have multiple groups, each containing some of the same elements. This makes it easy to chase anything you want, even if they’re unrelated. You could chase all of the reds or the entire display no matter what color it is.

aussiephil
12-15-2011, 06:24 PM
The little bit of play with this say’s that you can have multiple groups, each containing some of the same elements. This makes it easy to chase anything you want, even if they’re unrelated. You could chase all of the reds or the entire display no matter what color it is.

As Ernie has said, just create another Group with those channels in the group, the examples I have used and others have talked about grouping things like minitrees but nothing stops you making as many groups with even logically unrelated items grouped. Groups such as colour groups i used in the demo video are exactly that.

The ability to group items contains so much power, it's just hard to break out of the Grid.

corytcline
12-15-2011, 10:19 PM
I understand grouping the tree together mine for example has five channels on it so to me it made sense to group them together. My bushes are the same 5 seperate channels for them so I grouped them together. Everything else in my display is just single channels on a bush here and there and of course my roof line and around a couple of windows. So you are saying to group say my roof with the windows and a couple of bushes then run a chase on them? This sounds simple enough but then it makes you have to look in those groups for one channel if you want to turn just that one channel on right?
For example when I grouped my tree it is channels 11-15. Now the only place I see those channels are in that group instead of in the normal channel line up somewhat confusing.
As far as turning on all the red or all the blues I have not yet reached that status I don't near have the light to have three colors ran everywhere someday I will just not yet.
I am almost as new as they come and have no electronics background so If 3.0 needs to be played with by an "average guy" that is what you got here.

Aussiephil I was on the fence about trying this until I seen your video. You can take the credit for my decision to try, you cleared up a lot of my initial questions thanks for the video.
Cory T. Cline

aussiephil
12-15-2011, 11:23 PM
I understand grouping the tree together mine for example has five channels on it so to me it made sense to group them together. My bushes are the same 5 seperate channels for them so I grouped them together. Everything else in my display is just single channels on a bush here and there and of course my roof line and around a couple of windows. So you are saying to group say my roof with the windows and a couple of bushes then run a chase on them? This sounds simple enough but then it makes you have to look in those groups for one channel if you want to turn just that one channel on right?
For example when I grouped my tree it is channels 11-15. Now the only place I see those channels are in that group instead of in the normal channel line up somewhat confusing.
As far as turning on all the red or all the blues I have not yet reached that status I don't near have the light to have three colors ran everywhere someday I will just not yet.
I am almost as new as they come and have no electronics background so If 3.0 needs to be played with by an "average guy" that is what you got here.

Aussiephil I was on the fence about trying this until I seen your video. You can take the credit for my decision to try, you cleared up a lot of my initial questions thanks for the video.
Cory T. Cline

Cory, thank you, people that have been around for a while know i took a leave of absence from the hobby back in January this year. Vixen3 has been something that has got me enthused enough to make the little how to and start popping my head up. It's like a breath of fresh air to see Vixen3 heading in directions that I and others were thinking and speaking about 18 months ago, though not directly aimed at Vixen.

Now to you question: Yes i would create groups. Lets say your display has (the random items) 3 bushs on the left, 1 middle and couple more on the right plus say your roofline has say 2 sections as well as say 3 front windows. Here's some group ideas.
Group - Roofline - contains the 2 channels only
Group - left house - all items on the left side
Group - right house - all items on right side
Group - Chase Group 1 - All items at ground level.
Group - Chase Group 2 - Items left to right in logical order across up over roof and back down
Group - Chase Group 3 - Windows (even just 3 can be chased)

Because grouping is (for me) about logical visual arrangements based of effects I may want to apply it would be entirely possible on small display (< 64ch) to end up with more groups than channels if your display was composed on many varied items.
The larger the display the simpler grouping may become due to duplication of items.

sallz0r
12-15-2011, 11:25 PM
I understand grouping the tree together mine for example has five channels on it so to me it made sense to group them together. My bushes are the same 5 seperate channels for them so I grouped them together. Everything else in my display is just single channels on a bush here and there and of course my roof line and around a couple of windows. So you are saying to group say my roof with the windows and a couple of bushes then run a chase on them?

I'm not sure I 100% follow you, but I think it would be case of making a new group, calling it something like "everything", then putting all your different channels in there in the order you want to go through them in. Then you can apply a chase to the "everything" group, which would go through them in the order you define.

For example, in my display, I have a group: "stars". Within that group, I have a few other sub-groups: "stars-left", "stars-middle", "stars-right". Then in each of those I have 3 more channels: stars-1/2/3 in one, 4/5/6 in the next, and 7/8/9 in the last. I can apply a chase to just the left 3 stars, or another group, or I could apply a chase to ALL of them with the "stars" group.


This sounds simple enough but then it makes you have to look in those groups for one channel if you want to turn just that one channel on right?

Yep -- if you want to then do individual channels, drop down the list, and apply effects directly to the desired one. eg. I have a sequence where I bounce around on the stars with the melody, so I apply pulses in time to the music directly to each star, instead of using the groups.


For example when I grouped my tree it is channels 11-15. Now the only place I see those channels are in that group instead of in the normal channel line up somewhat confusing.

You can also have the same channel in multiple places -- like aussiephil's example with the groups of particular colored items. But you might want to have a group called "roof items", or "all windows" or something. Then those channels could exist in the "Windows" group, or in the "everything" group.

It's a good idea to get away from the idea of "a normal channel line up" -- grouping them, and having them organized into logical sections, *is* the "normal channel lineup"! :-)

(but, if you find you really need to have the list of channels in order, and find it easier to work that way, you can just have all the channels sitting individually at the root of the tree -- not in any groups -- and work on them that way. You won't have the power of some effects, since they need to be applied to groups, but you can still work with some of them.)

Hope that helps!

aussiephil
12-15-2011, 11:29 PM
Sallz0r - So strange to have someone in the same timezone answering at the same time :)

sallz0r
12-15-2011, 11:38 PM
Whoops, forgot to reply to this from a few days ago....


I'm actually struggling with the statement "There shouldn't be any nodes or groups that tie you specifically to controllers" as you must eventually map a node to an output channel and by far the easiest way is to create the channels as nodes and let the system automap them, renaming them after that is (IMO) a bit of a waste of time.

True -- that's the easiest way to get the auto-patched channels, instead of manually patching everything yourself. I didn't explain myself clearly; the point I was trying to make was that it's a good idea to think of the channel/group management window purely in a 'logical grouping' or 'abstract' mental space -- ie. a completely top-down view. It's a good idea to describe everything (all your channels and groups) in terms of *what* they are, like "star-3" or "tree tops" or "House left wall lights" or something. I'm sure you'd agree that it would be a bad idea to have a group named something like "Renard channels 12-24". :-)

Hence what I was saying about your video was quite a trivial point; it was more the encouraging of that frame of mind that led me to point out that you could renamed those channels to be what they actually are rather than leave them with default names (generated from the controller name). But you obviously understood the whole concept, I was just being finnicky. ;-)



Oh by the way the reason the blue trees require to individual channel nodes is because they effectively have 2 independent strings that need individual control

Sure -- and the way you did it would have been the quickest and easiest, and would have given the same result. (actually, I just realize, in some cases, not. But I digress.) Again, it just depends more where you want to do the abstraction: it only represents an individual tree, so make the node called "blue tree 3" and then patch it to the <x> different outputs needed to turn it on fully. Again, trivial.



Oops never got back to that, sorry, at the moment the usage of the gradient box to me is still a mystery, if i select a colour at 0% say red the box shows red, then drag the slider to 100% and select blue the box changes to blue, whereas i would expect it to show a red to blue gradient.

Aah! Right! Forgot to put a message there about that. If you click below the bar (where the first square is), you can add new squares, and change the new color. Those boxes just mark fixed color points.

Hope that helps! :-)

sallz0r
12-15-2011, 11:39 PM
Sallz0r - So strange to have someone in the same timezone answering at the same time :)

Haha, yeah, very bizarre. :-)

I should retract my last explanation to Cory. Yours was much better. :-)

corytcline
12-15-2011, 11:49 PM
thanks your explanations made some sense to me I have to admit to not being on of the smarter guys on this site I have one 24 channel renard at the moment and another on the way with plans for a third by next year and even at 72 channels that is still a small display compared to others on here.I'm gonna stick with this 3.0 and try to learn with everyone else. Hopefully next year I will be running my show from 3.0 I have only made 5 sequences from 2.1 so I'm still learning how to run it good to.So even though 3.0 is so different from 2.1 they are both new to me which makes the challenge to learn 3.0 the same to me as learning 2.1.

Sorry if I am a little hard to follow I just don't know all the terminology I do my best

sallz0r
12-16-2011, 12:00 AM
Sorry if I am a little hard to follow I just don't know all the terminology I do my best

No worries! Never a worry at all -- I think everyone here is pretty happy to help out whenever possible. We've all been there, and know it's pretty tough getting started and figuring everything out. :-)

prof
12-16-2011, 05:26 AM
With regards to combining multiple effects such as the the "spin and fade example" given by ausiephill. These efects, as phil stated, could be achieved in V2.x by using the various paste options such as transparent, boolean etc.

So in V3 would it make sense to have an option whereby you could choose to link multiple effects together and as part of the linking procedure you would select your mode of layering the effects to acheive the desired result and this would be where you could tie in all the old paste options.

Prof

aussiephil
12-16-2011, 08:59 AM
With regards to combining multiple effects such as the the "spin and fade example" given by ausiephill. These efects, as phil stated, could be achieved in V2.x by using the various paste options such as transparent, boolean etc.

So in V3 would it make sense to have an option whereby you could choose to link multiple effects together and as part of the linking procedure you would select your mode of layering the effects to acheive the desired result and this would be where you could tie in all the old paste options.

Prof

Prof,

Hi mate,

Unless the devs have some magic code up the sleeve, the only real way to make it work in the object based world (groups/nodes) is to be able to apply weighting (priorities) to either the effects or the groups or both.
Example: higher weight number = high priority
Spin effect - Weight = 100
Fade effect - Weight = 100
Both effects would combine with the highest output value being sent, ie the spin would not fade and would actually become visible

Spin effect - Weight = 100
Fade effect - Weight = 110
In this case the fade has the higher priority so the spin would not be visible at all as everything fades down

Spin effect - Weight = 110
Fade effect - Weight = 100
In this case the spin would be always visible whilst the rest of the display fades down.

Now that i have written that out the only way to achieve the fading spin is to literal apply the boolean logic as property settings on the effects. That way the output engine looks at the properties and renders the boolean values. Is this an options, over to the Devs to answer.

I still like the idea of being able to apply weighting values to handle a majority of cases.

Phil

sallz0r
12-16-2011, 09:08 AM
To be short and sweet, that's something that's being discussed at the moment, actually. There's a few other (related) things that affect everything, and it all sort of intertwines. So, no definite answer yet. But it's good to have a list of features that people want, or use cases for the specific feature..... so we can get the same functionality in some way or another.

(nudge nudge, wink wink -- perfect time to use the bug tracker / feature tracker -- bugs.vixenlights.com!) ;-)

bobkeyes
12-16-2011, 01:19 PM
The video is great Phil. Thanks a lot. I have one problem! When you drag an effect to a group is shows up graphically on the group. Mine does not show that. It is simply a gray bar with the effect named, start time, and length. Wonder why mine doesn't show the graphics yours does??

bobkeyes
12-16-2011, 01:44 PM
The video is great Phil. Thanks a lot. I have one problem! When you drag an effect to a group is shows up graphically on the group. Mine does not show that. It is simply a gray bar with the effect named, start time, and length. Wonder why mine doesn't show the graphics yours does??

Never Mind!! I figured it out. I had not assigned the controller to the groups. When I did that everything came up as it should.

bobkeyes
12-16-2011, 03:15 PM
The video is great Phil. Thanks a lot. I have one problem! When you drag an effect to a group is shows up graphically on the group. Mine does not show that. It is simply a gray bar with the effect named, start time, and length. Wonder why mine doesn't show the graphics yours does??

Never Mind!! I figured it out. I had not assigned the controller to the groups. When I did that everything came up as it should.

budude
12-16-2011, 03:34 PM
The more I think of this method of "objectifying" display items and having a particular set of lights in multiple nodes/objects has my head swimming on the capabilities. You could define all of your lights into an "Entire-House" object and do a Holdman style left-to-right fade in one simple action - make a couple for different colors - no problem - I'm liking it a lot!

bobkeyes
12-16-2011, 08:33 PM
I have a couple of elementary questions. Will there be a way to slow the music so that the light will be just perfectly timed? And, will the moving cursor be able to be moved slowly, kinda like the "scrub", I think it's called, in LSP?

From what I have seen I think it is fantastic. My hat is off to KC and the entire team. Kudos all around!

lowrider3121
12-16-2011, 11:03 PM
Great video Phil was having a hard time with Vixen 3

Jrd
12-17-2011, 01:38 AM
Hate to go off-topic but:

Phil I have been trying to reply to your PM from Monday but your box has been full.

JonathonReinhart
12-18-2011, 04:29 PM
Will there be a way to slow the music so that the light will be just perfectly timed? And, will the moving cursor be able to be moved slowly, kinda like the "scrub", I think it's called, in LSP?

These are two features that we are working on now, and would like to get in place as soon as we can.

For reference, they are VIX-48: Sequencer needs visualization of audio waveform in grid (http://bugs.vixenlights.com/browse/VIX-48) and VIX-44: Sequencer needs playback speed (http://bugs.vixenlights.com/browse/VIX-44).

All open issues in Vixen can be found in the bug tracker here: http://goo.gl/5hGRW

sallz0r
12-18-2011, 08:48 PM
For those that are interested to see what 3.x is capable of -- I recorded my display last night, and put videos up. You can see the results below!

http://www.youtube.com/watch?v=wfgOrwJO4ik
http://www.youtube.com/watch?v=0ER1kl6w8Po
http://www.youtube.com/watch?v=eRi70lFkxIM

bobkeyes
12-18-2011, 09:41 PM
Simply outstanding. Just great. That's what I've been looking for. Not sure how you did it so well without being able to slow the music. Could you let us in on that?

sallz0r
12-18-2011, 09:47 PM
Simply outstanding. Just great. That's what I've been looking for. Not sure how you did it so well without being able to slow the music. Could you let us in on that?

Lots of trial and error, and a good eye. ;-)

Mostly I just tapped out the beat tracks that I would use, then spent a while getting them right. I would put a single pulse against each beat on a specific channel (usually the drums), then played it back, and made sure the display preview showed it in time. I would spend a good hour or two just getting the beat markers right. Then it was just a case of working from them.

bobkeyes
12-18-2011, 09:50 PM
I get the good eye part and the trial and error. Mine is mostly error.

Thanks for showing it. It is going to be a powerful piece of software. Well, I guess it already is!!

Blackbeard
12-19-2011, 08:25 AM
For reference, they are VIX-48: Sequencer needs visualization of audio waveform in grid (http://bugs.vixenlights.com/browse/VIX-48) and VIX-44: Sequencer needs playback speed (http://bugs.vixenlights.com/browse/VIX-44).

All open issues in Vixen can be found in the bug tracker here: http://goo.gl/5hGRW

These links don't seem to be too helpful. Do I need to subscribe to anything to see something useful?

sallz0r
12-19-2011, 08:43 AM
These links don't seem to be too helpful. Do I need to subscribe to anything to see something useful?

I'm not sure if public access has been set up, or if you need to have an account to view bugs. If so, it's free and easy to sign up.

SCBonner384
12-19-2011, 12:50 PM
Hi sallz0r,

That’s was an amazing display and a great representation of the displays that have made me want to venture down this path of Christmas displays. I have never created a display of any kind and my questions may be very trivial and well known but I am a bit overwhelmed by eveerything I have seen and read so far. Here are my questions that may be helpfull to complete Newbs like me.

1. I have never used any type of Sequencing software before, so, should I start with 3.0 or is starting with an earlier version like 2.5 a better step for me and others just starting out?

2. In the first Post of this thread, KC Mentions not to use this Beta version with a High Channel count but I see from your comments on your “AWESOME!!!!” YouTube Video that you have some 1200 individual Channels. Obviously, that is a crazy High number to me but now I wonder what the limitations actually are for Beta 3. What is the suggested Channel Max per Com Port and how many Com Ports are supported?

Thanks for all the information to date, Still trying to wrap my head around it.
Scott

CaptKirk
12-19-2011, 03:34 PM
Is that all Renard serial?? ASTOUNDING. I am awestruck. I too want to know how many channels!!

Kirk

sallz0r
12-19-2011, 08:28 PM
1. I have never used any type of Sequencing software before, so, should I start with 3.0 or is starting with an earlier version like 2.5 a better step for me and others just starting out?

I commented on something similar in another thread..... actually, I'll find that and quote it here instead...... :


I'd recommend a bit of both, to get a good feel for how it all works. There's quite a big paradigm shift between 2.x and 3.x, and the way you have to think about it to put things together.

Id recommend starting off a bit with 2.x -- it's tried, tested, and there's lots of information around for it. You can make a few quick test sequences, to see how it works, how controllers, channels, and everything else works -- but I wouldn't spend too much time actually making sequences. Maybe play around with it for a few hours, and actually get it working with your controller(s) to understand the process.

Then, with a bit of a basis in how that much works, have a crack at 3.x. It's not particularly user-friendly at the moment, since there's an assumed level of knowledge, so I could see how someone starting fresh would find it confusing as hell. But, by all means -- please ask questions, and tell us what you don't understand! We want to make it better, and need user-feedback for that. :-) A lot of the time, we've worked on it so much we don't know how confusing something is getting.

But, I'd definitely recommend *not* spending too much time sequencing in 2.x. I believe you'll be much better off using 3.x, as it will be the more future-proof option. (There should be more betas out early next year, which will have more improvements, etc.)



2. In the first Post of this thread, KC Mentions not to use this Beta version with a High Channel count but I see from your comments on your “AWESOME!!!!” YouTube Video that you have some 1200 individual Channels. Obviously, that is a crazy High number to me but now I wonder what the limitations actually are for Beta 3. What is the suggested Channel Max per Com Port and how many Com Ports are supported?

That recommendation is only because it's beta software, and hasn't been tested fully with high channel counts, and we know there's some efficiency issues in there with high channel counts. I've made a few bandaid fixes to get it working for my uses this year, but I could imagine it would be pretty painful for end-users to try and use it for a display in the current state.

Fortunately, I've found lots of interesting things out about the software using a high channel count, so should be able to use that to improve the software in the new year. I would expect to be able to use 3.x with very large channel counts; well, that's the goal, at least. :-)

As for the questions about channels per com ports, etc., that's dependent on the controller you're using. You'll have to check with others that are using a similar control system to yourself.

I don't think there would be a limit on COM ports supported; you could just keep adding new controllers in the software for each COM port you have.

sallz0r
12-19-2011, 08:30 PM
Is that all Renard serial?? ASTOUNDING. I am awestruck. I too want to know how many channels!!

It's all a custom control system I've developed, actually; It's over ethernet, and I've built some custom ethernet -> RS485 boards. I've got 8 different RS-485 streams, and I can easily add more in future, so I could have an almost unlimited amount of channels; I'd only be limited by what the software can support, and by the available ethernet bandwidth. :-)

boarder3
12-19-2011, 10:30 PM
I cant wait for this to be done it looks great. I want to start test some effect for my rgb's for next year now any idea when this thing comes out of beta?

sallz0r
12-19-2011, 11:12 PM
any idea when this thing comes out of beta?

Hopefully if we can get enough feedback from users and testing with different systems we can focus on improving and refining it in the new year, and helping to develop the other modules that would be needed.

I would hope that 3.0 would be usable by people for their displays next year. We just need to generate the community discussion on everything to establish what other features and modules we need to incorporate to make sure it can do what people need. :-)

dirknerkle
12-19-2011, 11:32 PM
We just need to generate the community discussion on everything to establish what other features and modules we need to incorporate to make sure it can do what people need. :-)

But then again, people need enough time to "start over" with their sequencing and learn a new tool besides, so you may decide to focus on the basics and system stability, and get the product out so people have enough time to put it into action.

Of course, I'm not telling you anything you didn't already know... but sometimes it's helpful to be reminded that going the way that LSP's development has is probably not the road you want to take....

Jrd
12-19-2011, 11:39 PM
Has there been another release since the download listed above?

sallz0r
12-20-2011, 12:04 AM
But then again, people need enough time to "start over" with their sequencing and learn a new tool besides, so you may decide to focus on the basics and system stability, and get the product out so people have enough time to put it into action.

Very true! Don't get me wrong, I'm not saying we need to add every last whiz-bang feature that might possibly be requested; but at the other end of the spectrum, it's pretty clear that 2.x wasn't quite cutting it for a lot of users. There were plenty of 3rd party scripts, plugins, and everything else to try and reverse-engineer functionality into the software that it never really supported, which all started becoming unwieldy.

I'm not suggesting we implement everything now; but we just want to make sure the framework and system would support the style of things people want to do with it in future. There's already been heaps of things discussed in this thread that are good food for thought -- dimming effects after they're applied, working with color other than RGB (eg. RGBW, RGBYW), and so on -- I just want to try and get a good finger on the pulse of the community to make sure we aren't going to have something big in 9 months time that makes us go "oh, crap. We didn't think of that."

That's sort of the whole point of the beta: giving people a chance to see where the idea of the software is going, learn how things are going to be different, and let us know what bits just don't make sense, are hard to use, or take too long, etc. It's obviously not finished, but should give a pretty solid overview of how everything would go together. :-)


Of course, I'm not telling you anything you didn't already know... but sometimes it's helpful to be reminded that going the way that LSP's development has is probably not the road you want to take....

Any feedback -- positive or negative, or somewhere inbetween -- is good. :-)

Although I must say I haven't played with LSP, and haven't followed many of the discussions, so I'm not understanding what you mean with your comment. What happened with LSP? What is good or bad about it -- well, why don't we want to take the same road?

sallz0r
12-20-2011, 12:07 AM
Has there been another release since the download listed above?

Nope. There hasn't been a huge amount of changes; I think a lot of people have been busy with their own lights and/or family/holiday commitments. :-) Hopefully from the community feedback we'll get a better sense of where things are going, and can start some of the bigger changes going in the new year, and polish things up to work a bit better.

Jrd
12-20-2011, 12:12 AM
Nope. There hasn't been a huge amount of changes; I think a lot of people have been busy with their own lights and/or family/holiday commitments. :-) Hopefully from the community feedback we'll get a better sense of where things are going, and can start some of the bigger changes going in the new year, and polish things up to work a bit better.

OK, I was just wondering because you mentioned you did some tweaks so it would work with your display.

sallz0r
12-20-2011, 12:18 AM
OK, I was just wondering because you mentioned you did some tweaks so it would work with your display.

Oh, right -- nah, they were just very minor things, to make it easier to sequence (disabling the preview rendering on the effect blocks -- otherwise it takes a REALLY REALLY long time to open up a full sequence), a small tweak to the scheduler, stuff like that. Things that I will fix properly in the new year, rather than my ugly hack fixes that I have now. ;-)

dirknerkle
12-20-2011, 12:22 AM
Although I must say I haven't played with LSP, and haven't followed many of the discussions, so I'm not understanding what you mean with your comment. What happened with LSP? What is good or bad about it -- well, why don't we want to take the same road?

Long on promises, short on delivery. Lots and lots of whiz-bang effects and how-to videos/demos yet the basics such as talking to various controllers hadn't been flushed out and was/still is inconsistent at best. Ghastly slow; better now but still slow by any reasonable standards. Common features such as undo were inconsistent or didn't work at all. Said to import Vixen (and other sequences) but these features are still problematic and inconsistent. You get the idea...

sallz0r
12-20-2011, 12:30 AM
Long on promises, short on delivery. Lots and lots of whiz-bang effects and how-to videos/demos yet the basics such as talking to various controllers hadn't been flushed out and was/still is inconsistent at best. Ghastly slow; better now but still slow by any reasonable standards. Common features such as undo were inconsistent or didn't work at all. Said to import Vixen (and other sequences) but these features are still problematic and inconsistent. You get the idea...

Aah, right. Yeah, that makes sense. We definitely do want to make sure it's stable and usable for everyone, and hopefully don't get that sort of reputation. I know it's a fairly ambitious project, and has a lot of potential, but want to make sure it's done right. :-)

Thanks for your comments.

aussiephil
12-20-2011, 03:53 AM
For those that are interested to see what 3.x is capable of -- I recorded my display last night, and put videos up. You can see the results below!

http://www.youtube.com/watch?v=wfgOrwJO4ik
http://www.youtube.com/watch?v=0ER1kl6w8Po
http://www.youtube.com/watch?v=eRi70lFkxIM


Sallz0r

Looking awesome. It was good to see how the current effects could be used to drive a great looking display. Can't wait to be able to play with it with real output and test against my 7.7k channels. I might finally have software were I can really use to give full colour effects.
I'm sure you can guess my excitement is high

Any news on the DMX or E131 outputs?


Offtopic: jrd - looking into clearing things

smartalec
12-20-2011, 05:40 AM
Any news on the DMX or E131 outputs?

I would love to start testing vixen 3, but until e1.31 comes out for it im unable too.

Hope something happens soon..

boarder3
12-20-2011, 09:26 PM
i would be happy with vixen with real rgb support and from what i see this goes way beyond that which is great. I tried to use lsp what a disaster paid for it and never got it to output without glitching ended up going back to vixen. 3900 channels the hard way but it works so thanks. I hoping they add a matrix support to so i can use my rgb strips as a sign. Any talk of that?

sallz0r
12-20-2011, 09:33 PM
I hoping they add a matrix support to so i can use my rgb strips as a sign. Any talk of that?

I think it was earlier in the thread we discussed the idea of supporting pixel displays more effectively; using something like a 'grid' property where you can configure some groups/channels as a two-dimensional array, then we could make effects that utilize that. So, there's talk of it, but it would be quite involved. :-)

JHinkle
12-23-2011, 11:48 PM
I have my system running using Level data per the training videos.

I am developing a controller that will accept hi-level commands as in Channel 5 - start at level 5 and ramp to level 90 over the next 5500 millisecs.

In reading all of the early documentation - I thought I could trap the Command and get access to hi-level effect data.

Is that going to be possible or did I just read into the capabilities what I was hoping for.

If - TRUE - is there documentation that would help me get access?

Level is available as Lighting.Monochrome.SetLevel.

Do I look for event properties?

Thanks in advance for any reply - I'm just not sure how to properly word the request.

sallz0r
12-24-2011, 04:52 AM
I am developing a controller that will accept hi-level commands as in Channel 5 - start at level 5 and ramp to level 90 over the next 5500 millisecs.

In reading all of the early documentation - I thought I could trap the Command and get access to hi-level effect data.

Is that going to be possible or did I just read into the capabilities what I was hoping for.

I'm not sure I fully understand what you're trying to do, so please correct me if I'm misunderstanding. :-) Are you trying to get information about the high-level effects? From a controller's point of view, you don't have any of that -- the only thing a controller gets or knows about is commands. Nothing high-level.

What exactly are you trying to achieve? We're in the process of discussing it all at the moment, to possibly make some other changes that might relate to this. If we understand what you're trying to get at, it might be useful input. :-)

JHinkle
12-24-2011, 09:48 AM
OK.

Today - most everyone is communicating raw intensity levels out to the controllers on RS232, RS485 etc. These have bandwidth concerns as the channel count goes up and/or the frequency of update goes up --- lets assume we want only one bus (RS485) to communicate on and several hundred channels.

One way of greatly reducing the bandwidth utilization is to reduce the amount of data - so only tell the controller to change a channel when an "effect" changes: Change intensity level (if same level for at least a standard length of time), ramp intensity up from start intensity to final intensity over a length of time, ramp intensity down from start intensity to final intensity over a length of time.

Every illumination event I saw on the videos Phil made could be described in those three type of events (changing dimming was changing changing line segments), etc.

It appears Version 3 is doing the same above and just figuring out the raw intensity level at each time interval. If "THAT" high-level segment command (change intensity, ramp up, ramp down) was available at event change to the Output Module (I was hoping) - I intended to use THAT data and not intensity level for my communication protocol.

As an example --- see below --- message packet is bit packed and variable length as only change is communicated

Start token
Controller ID
Msg Length
Channel ID
Channel Cmd
Channel Cmd data
.....

Channel ID
Channel Cmd
Channel Cmd data
Checksum
End token

The controller would have to have a fast cpu (I'm using Freescale Star12 - 16 bit - instruction cycle time of 20Mhz - $7 to $10)

Only change from today - is besides performing PWM - the cpu now quickly determines the resolution of pwm change over a period of time.

As a side benefit - you can have changes occurring on a finer scale than 25 millisecs and have more than 256 levels of intensity because they are all local to the controller and not impacting communication bandwidth.

I was going to write my own sequencer but got excited when I read the early notes on version three.

Hope that helps.

Merry Christmas

sallz0r
12-24-2011, 09:54 AM
OK.

<snip>

Hope that helps.

Gotcha!

Yep, that makes perfect sense. It's what I thought you were meaning, but couldn't read into it that much from your last post.

Thanks for the info, I didn't realize there's that sort of desire for that sort of data out there as well. It's an interesting idea. I'll mull it over for a while, throw a few things up in the air, and see what sticks.... hmm.....

Merry Christmas to you all!

JHinkle
12-27-2011, 01:44 AM
I'd like to propose two ideas for the team to consider.

#1.. Add another level of hierarchy to the Output Module.

Add a Communication Path above Controllers.

The Path would capture COM port info as Controller does today. Think of that as one of your RS485 buses. The COM port and Baud rate is common to all controllers that fall under it.

Then your Controller level - which would simple capture a Controller ID.

Those not using a bus could still roll everything into Controller.

Those using a bus - now the Output Module would keep the COM port open for multiple controllers and as Vixen called to output each Controller - the output would build just that controller's message frame.

Nice and clean and object oriented.


#2. Please consider having a configuration setting where the user could identify a default, or better yet - per channel - max size number to represent 100% intensity.

As I continue with my controller design, I find I can Zero-Cross PWM to 12 bits or 4096 levels.

Doing a simple numeric expansion from 8 bits to 12 bits in the output module doesn't provide the granularity of intensity change that Vixen could produce by have the number of bit associated with the output data be configurable.

By the way ... I posted about the controller I'm designing and someone stated they would like a non-linear intensity curve and suggested it be part of the controller.

THE place for that translation is in the Output module where, instead of taking Vixens output value and sending it, it is used as an index into a table which contains the modified lighting curve.

The poster stated that a non-linear curve made a night and day difference in RGB LEDs he saw.

People could do THAT right now with Vixen 3 and improve the LED dimming profile.

klyneshouse
12-27-2011, 02:30 PM
I'd like to propose two ideas for the team to consider.

#1.. Add another level of hierarchy to the Output Module.

Add a Communication Path above Controllers.

The Path would capture COM port info as Controller does today. Think of that as one of your RS485 buses. The COM port and Baud rate is common to all controllers that fall under it.

Then your Controller level - which would simple capture a Controller ID.

Those not using a bus could still roll everything into Controller.

Those using a bus - now the Output Module would keep the COM port open for multiple controllers and as Vixen called to output each Controller - the output would build just that controller's message frame.

Nice and clean and object oriented.
..............
.




Forgive me if I am missing something but will the base timing still reside on a per sequence basis, ie 25 ms, 50 ms, etc. ?
Or does 3.0 somehow dynamically configure it ?
Or worse default to the highest ?
I was not able to see it anywhere.

In other words would it be possible to mix and match for instance REN x-bee wireless @ 50 ms and utilize E1.31 @10ms in the same sequence? Or would something like remote client plugin be required?

TimW
12-27-2011, 07:05 PM
I have my system running using Level data per the training videos.

I am developing a controller that will accept hi-level commands as in Channel 5 - start at level 5 and ramp to level 90 over the next 5500 millisecs.




By the way ... I posted about the controller I'm designing and someone stated they would like a non-linear intensity curve and suggested it be part of the controller.

THE place for that translation is in the Output module where, instead of taking Vixens output value and sending it, it is used as an index into a table which contains the modified lighting curve.

The poster stated that a non-linear curve made a night and day difference in RGB LEDs he saw.

People could do THAT right now with Vixen 3 and improve the LED dimming profile.


Loving the design discussion. Thanks.

But if THE place to do linearity correction is the vixen 3 output module ..... how will your parameterised high level commands account for it???? On one hand you are concerned with bandwidth utilization and in the next step you are suggesting that the distance between incremental 12 bit dimming levels should be determined at the PC?

Doing the dimming curve conversion in vixen is, um, not exactly new?! For some implementations it makes good sense. But SHOUTING (in caps) will never make the assertion true in all cases. (And IT HURTS MY HEAD) :)

Respect.

Tim

JHinkle
12-27-2011, 08:16 PM
They are two different ways to control lighting. When you create your own firmware, you have the luxury to to do multiple things.

I would like to see both Hi-Level commands be available to the Output module as well as Output Values greater than 256.

I'm very excited about what an individual can do himself in the Output module. Once people understand, it will take the capabilities of your light shows to another level.

Today, a controller accepts what the sequencer (Vixen) provides and ships that raw data out to controllers.

If ALL of the potential had to be wrapped into the controller, there would be a lot of confusion as to what to buy, when, how, etc.

As new technology comes available - as we see lately in the LED arena - people might feel they have to change --- but maybe not.

If Vixen could provide me with Hi-Level events. I can choose what to do with them. I might want to ship it to a controller and let it process it. I may want to further crunch the event myself locally and derive my own raw data ... no longer limited to 256 - If I received an event that said fade from X to Y in Z seconds - I could output my own data stream and have capabilities not available elsewhere - I could ship 12 bit data or higher if I wanted.

Everyone has the capability today to modify the illumination curve associated with each string of lights or LEDs. Just process the data a little more in the Output Module before you ship it to the controller.

So - my requests are different but they do overlap.

The potential is just waiting to explode.

sallz0r
12-29-2011, 12:57 AM
#1.. Add another level of hierarchy to the Output Module. Add a Communication Path above Controllers.

The Path would capture COM port info as Controller does today. Think of that as one of your RS485 buses. The COM port and Baud rate is common to all controllers that fall under it. Then your Controller level - which would simple capture a Controller ID. Those not using a bus could still roll everything into Controller.

Those using a bus - now the Output Module would keep the COM port open for multiple controllers and as Vixen called to output each Controller - the output would build just that controller's message frame. Nice and clean and object oriented.

Either I've missed your intent with this request, or missed how people set up their controllers. :-) As I understand it, the output modules/controller modules are generally set up per bus, or per stream: So, for example: if you have 10 different physical controllers/boards, each with 16 channels, and all connected to the same bus (which is coming from a single physical serial port on your PC, say)..... you would configure in software one instance of that controller module, with 160 channels, and configure the serial port for that bus as needed.

I haven't used a renard system, or many of the others, but the ones I have used work like that, and it's how I understand a lot of the others work as well.

So, as far as I can tell, your request is sort of how it's intended to be used at the moment: eg. the serial settings are common to all controllers that fall under it, and it's all common to a single 'bus', or stream, and doesn't need you to configure specific details for each controller/board. (If a particular output module wants to let you do that, or *needs* you to do that, then by all means it can add that to its setup page: but it's not something we can abstract out accurately, as different systems would expect and operate differently.)

If I've missed something, please let me know. :-)



#2. Please consider having a configuration setting where the user could identify a default, or better yet - per channel - max size number to represent 100% intensity.

As I continue with my controller design, I find I can Zero-Cross PWM to 12 bits or 4096 levels.

Doing a simple numeric expansion from 8 bits to 12 bits in the output module doesn't provide the granularity of intensity change that Vixen could produce by have the number of bit associated with the output data be configurable.


There's nothing restricting you to 8-bit (or 12-bit, or 16-bit) values: at the moment, the 'Level' command simply specifies a floating point number from 0 to 100, to represent intensity. You can interpolate any value you'd like from that; heck, if you wanted to, you could get a 32-bit value if needed. :-)

(Having said that, I know the pulse effects are rendered to commands for discrete levels; I can't remember off the top of my head, but I vaguely remember it's differences in level of 0.1 or so. This would effectively negate any benefit to using a precise level in the Level command, I know. :-) But that's something that's not going to be in there long-term; it's part of a discussion on changes we're having at the moment, actually.)


By the way ... I posted about the controller I'm designing and someone stated they would like a non-linear intensity curve and suggested it be part of the controller.

THE place for that translation is in the Output module where, instead of taking Vixens output value and sending it, it is used as an index into a table which contains the modified lighting curve.

The poster stated that a non-linear curve made a night and day difference in RGB LEDs he saw. People could do THAT right now with Vixen 3 and improve the LED dimming profile.

There's a heap of different ways to deal with a non-linear lighting response. You could do it in the controller, as you've said, but that means you have to make some assumptions about what you're driving in the controller code. (If it's a controller for a specific item, or you're written it to work with only LEDs, or certain types, then that might be fine for your uses.) Or you could even do it in hardware; but then you might have the same problems, it depends on each scenario. Or, you could use dimming curves: for each output on a controller, you can associate transforms. There's only one at the moment --- a dimming curve -- which does exactly what you're after. So that could be another solution as well.

That sort of thing is very useful for different styles of incandescents, where each type of bulb might have a different intensity response curve for different values, so it's handy to be able to customize each output with the appropriate value. Maybe LEDs are all pretty similar, since they're more immediate to respond? I don't know.

Hope that helps! Let me know if I've misunderstood anything, or haven't answered what you're after fully.

sallz0r
12-29-2011, 01:53 AM
Forgive me if I am missing something but will the base timing still reside on a per sequence basis, ie 25 ms, 50 ms, etc. ?
Or does 3.0 somehow dynamically configure it ?
Or worse default to the highest ?
I was not able to see it anywhere.

In other words would it be possible to mix and match for instance REN x-bee wireless @ 50 ms and utilize E1.31 @10ms in the same sequence? Or would something like remote client plugin be required?

No, there's no hard timing configured per sequence, it's all on a (relatively) continuous time line. Controllers are able to configure the rate at which they're updated -- I think it's configured as an interval in ms -- but that's up to the output module writer to configure in code, or present an interface to the user if it's one that should be customizable.

So, from the user's point of view, you can just sequence things to happen as close to the desired time as possible/needed, and let the system take care of the rest. :-) The controller will update the outputs with the new values as close to the desired time as possible.

aussiephil
12-29-2011, 02:35 AM
What an interesting set of posts in the last few days.

I see some benefits in sending very high level info to a controller and letting the controller do it's thing, but not at a channel level, rather at the object level. The controller looks after one object like a megatree for instance and you just send a high level command to spin the tree. This would involve two way comms (TCPIP anyone) to ensure the command arrived and was resent in the event of no response from the controller.
Sending this data at a channel level is already proven to have any number of issues, just talk to LOR users about lost commands and missing effects.
DMX and it's constant stream of information is used in the commercial world for very good reasons.

I have no idea why there is a concern about bandwidth using protocols like ACN/E131/DMX. Seriously my 1Gb ethernet port having 24 DMX universes over E131 at 25ms timings has less than 1% of bandwith used. Let's see that's somewhere around 240 universes at 10% and 480 at 20%, now apart from maybe MPH because he can who is going to have 240,000 channels in the next few years.

As for using 1024 levels or better to do hardware based curves, nothing new there RJ has done it for a number of years taking current 256 levels and applying hardware based curves using 1024 levels available in the control IC's. Even I've coded for it but never implemented it as DC based LED products in OZ actually have a fairly linear dimming curve using default 0-256 levels. No one I repeat no one including a number of commercial lighting engineers has ever commented that my LED setup using DC control had a bad curve.
Mind you for all the AC based systems and certainly our friends in the US then the story is a little different but thats not an issue with the current 256 levels available but the actual AC LED strings and AC dimming. Commercial AC dimmers have inbuilt hardware curves for very good reasons.

Using DC my controllers will turn on a LED string at DMX level 1 and typically an incan string at level 3, both strings will exhibit a linear brightness increase after that as measured by a light meter in a controlled test setup.
AC dimmers suffer from zero cross timing lag and zero cross distortion causing non linear dimming results early in the curve, this is best tackled by the hardware controller with a hardware driven curve.

Commercial DMX fixtures that have movement will usually take 2 dmx channels and the control desk/software will use a 16 bit number sent as 2x8bit values.

Sallz0r: I hadn't particularly noticed yet but i hope that all level data is processed with at least 8 bit (256) precision. LSP is using 0-100% and it is seriously a joke. I was concerned about your 100% answer in one of the replies
Vixen3 needs 8bit precision exposed to the user even if behind the scenes every level is a 32bit number, this would at least give the ability to expand if needed later.

Lastly, i hope that someone, and i say someone because it's past my ability, does do some sort of video import or at least a timing grid effect to allow for video at either 25fps or 30fps to be easily managed.

Cheers
Phil

sallz0r
12-29-2011, 03:12 AM
I see some benefits in sending very high level info to a controller and letting the controller do it's thing, but not at a channel level, rather at the object level. The controller looks after one object like a megatree for instance and you just send a high level command to spin the tree. This would involve two way comms (TCPIP anyone) to ensure the command arrived and was resent in the event of no response from the controller.
Sending this data at a channel level is already proven to have any number of issues, just talk to LOR users about lost commands and missing effects.
DMX and it's constant stream of information is used in the commercial world for very good reasons.

I guess it all comes back to intent and the way something is designed. I'm not saying we shouldn't have these discussions, or shouldn't consider these aspects of it -- but the way Vixen 3 is designed at the moment is almost the complete opposite of that. It's designed to be more of a linear reduction of intent into raw commands/values -- similar to what 2.x would output -- and have controllers handle that data.

Clearly, though, there's a desire for more. Unfortunately, that introduces complexity, and it's something that needs to be thought through carefully, to make sure that it still follows a logical design and structure, and doesn't consist of a hodgepodge of modules sticking their fingers where they shouldn't go. :-)



Sallz0r: I hadn't particularly noticed yet but i hope that all level data is processed with at least 8 bit (256) precision. LSP is using 0-100% and it is seriously a joke. I was concerned about your 100% answer in one of the replies
Vixen3 needs 8bit precision exposed to the user even if behind the scenes every level is a 32bit number, this would at least give the ability to expand if needed later.

There's not 100 discrete intensity levels available: it's a continuous range, using a floaing point value from 0-100. (Just arbitrary numbers picked to match the concept of a 'percentage'; we could go 0 -> 1, or 0 -> 30,000). The controller can deal with that value as needed. If it gets a "Set monochrome lighting level to 45.66%" command, it might render that to an 8-bit value of 116 and send it out the bus, or a 16-bit value of 29,923 and send it out however it wants..... so the scale is arbitrary.



Lastly, i hope that someone, and i say someone because it's past my ability, does do some sort of video import or at least a timing grid effect to allow for video at either 25fps or 30fps to be easily managed.

It's something that I'm fairly confident would be possible. No one's looked at it yet, and conceptually it should be relatively straightforward. But for the time being, we need to figure out what we want to do with the architecture, given the recent feedback. :-)

aussiephil
12-29-2011, 07:14 AM
Sallz0r:
I'm actually on the side of using standards such as DMX, E131, ACN etc (even Renard) all of which render the output inot time based slices of raw data.

Though with the clear direction towards the object based model if the code behind made provision for further "objectification" by potentially allowing the direct output of the effect intent then this may allow for future directions and visions.

I do believe that this is only practical at a full object level, i can't go much further down this road as some of what i would like to discuss may be covered by IP so need to check first.

Ah the 0-100 now makes sense and could be rendered by output modules as required, is it possible that the UI could optional (as vixen 2x does now) display that as 0-256 to cater for people deep into DMX?

Sorry to keep throwing ideas into the mix - now as things wind down i can look at adding things into the bug tracker

Cheers
Phil

kychristmas
12-29-2011, 10:50 AM
Admittedly, I have not read through all the posts regarding Objectification and High Level effect output, but I want to throw a my two cents in. If this is going to be an selectable option, then I'm all for it, but if its a either-or type of thing then I proposed to stick witht he current Raw-Data output.

My biggest concern is putting a lot of processing on the Output module. With a larger number of channels and very short event period, there will be a chance for timing issues on lower power machines.

I really don't see where the 99% ers benefit from this. I'm a developer and write C# applications for a living, but I don't want to have to develop and customize my own output modules. I also don't think it's good for the community to have a ton of Firmware and Plugin/Module Versions floating around. With the limited number of version of firmware out now, we see a ton of problem with new users running the wrong ones. I see the problems growing exponentially with this model.

...[character steps down from soapbox]

Kelly



Sallz0r:
I'm actually on the side of using standards such as DMX, E131, ACN etc (even Renard) all of which render the output inot time based slices of raw data.

Though with the clear direction towards the object based model if the code behind made provision for further "objectification" by potentially allowing the direct output of the effect intent then this may allow for future directions and visions.

I do believe that this is only practical at a full object level, i can't go much further down this road as some of what i would like to discuss may be covered by IP so need to check first.

Ah the 0-100 now makes sense and could be rendered by output modules as required, is it possible that the UI could optional (as vixen 2x does now) display that as 0-256 to cater for people deep into DMX?

Sorry to keep throwing ideas into the mix - now as things wind down i can look at adding things into the bug tracker

Cheers
Phil

sallz0r
12-29-2011, 11:49 AM
Admittedly, I have not read through all the posts regarding Objectification and High Level effect output, but I want to throw a my two cents in. If this is going to be an selectable option, then I'm all for it, but if its a either-or type of thing then I proposed to stick witht he current Raw-Data output.

My biggest concern is putting a lot of processing on the Output module. With a larger number of channels and very short event period, there will be a chance for timing issues on lower power machines.

I really don't see where the 99% ers benefit from this. I'm a developer and write C# applications for a living, but I don't want to have to develop and customize my own output modules. I also don't think it's good for the community to have a ton of Firmware and Plugin/Module Versions floating around. With the limited number of version of firmware out now, we see a ton of problem with new users running the wrong ones. I see the problems growing exponentially with this model.

That's a very good point, and thank you for pointing it out. If it's any consolation (and I'm only speaking for myself here), I've considered that side of it too, and figured that the majority of people would be working with simple displays where they want Vixen to do all the heavy lifting. Personally, that's all I want as well -- essentially, just something that is a more logical interface/grouping/method than 2.x.

Nevertheless, the points that are raised are certainly valid; but as I said previously, it all depends on the scope of the application, and what it's trying to actually *achieve*. But while discussing these things with people, getting various inputs, comments, and feedback, it's given good insight into how people want it to work, and what people want to achieve with it, all of which I think is useful. I've been mulling it over for the last few weeks, now, trying to find an architecture which satisfies *everyone* (well, OK, maybe just *most people*). ;-)

JHinkle
12-29-2011, 12:09 PM
Originally posted by sallzOr
Either I've missed your intent with this request, or missed how people set up their controllers. :-) As I understand it, the output modules/controller modules are generally set up per bus, or per stream: So, for example: if you have 10 different physical controllers/boards, each with 16 channels, and all connected to the same bus (which is coming from a single physical serial port on your PC, say)..... you would configure in software one instance of that controller module, with 160 channels, and configure the serial port for that bus as needed.

The opinion that follows is what I currently understand by looking at the various controllers on the forum.

As you stated - As defined by usage today - your definition of a bus for 10 controllers having 16 channels is one message containing all 160 channels of data that is serially passed to the next controller until all 10 controllers have received the complete message.

I believe that mechanism was put into place based on RS232 criteria because RS232 is based on single node-to-node communication. So the bus concept used by DIY networks is one of each controller being required to pass the nessage down to the next controller. If you have 10 controllers on this type of bus, controller 10 is receiving its message with quite a bit of delay compared to controller 1.

True RS485 bus construction and usage, as used in industrial systems and automotive networks (CAN) - are not designed and operated like that.

The bus is defined as a half or full duplex network when multiple controllers attach. The controllers are all in parallel - not serially linked. The message frame that is transmitted on this bus contains a ID that is unique to a specific controller. There is no serial passing of the message. Every controllers receives the message frame at the same time and determines if the message is meant for it. If so, it saves the incoming message and processes it.

My request is for Vixen 3 to provide for the use of this true bus configuration.

If the capability was provided, the the Vixen 3 Output Module would then process 10 different controllers. The Output Module would know the controller's ID (based on Setup) - and create a message frame for that controller only. That message frame would then be sent out on the COM port specified for the BUS. You would have 10 different message frames being transmitted on the COM port bus.

Can I use Vixen 3 as designed today - Yes. My Output Module receives all 160 channels as you earlier pointed out. My Setup allows me to take the 160 channels and assign them to 10 different controllers, each assigned a unique ID. I make multiple passes through Vixen's 160 channel output array - each time removing data specific to a specific controller and then ship just that controller's message frame.

In this case, controller 10 is receiving its message at the same time controller 2 would receive it's message using the DIY "serialized bus"

Is this request a departure from 99% of those using Vixen today? Yes. I'm requesting that the tool provide the capability to move from DIY towards industry standards.

I retract my request for "Event" notification to the Output Module.


Originally posted by sallzOr
There's nothing restricting you to 8-bit (or 12-bit, or 16-bit) values: at the moment, the 'Level' command simply specifies a floating point number from 0 to 100, to represent intensity. You can interpolate any value you'd like from that; heck, if you wanted to, you could get a 32-bit value if needed. :-)


Please excuse my ignorance as to my next question. I have never used Vixen 2 - I just found your site and am excited by Vixen 3.

The user interface uses 0 to 100% to identify illumination levels.

Is there a setting or configuration that tells Vixen what size of number to convert 100% into?

Is the default a byte (255)? Where can that be changed. Is there somewhere to tell Vixen 3 - make 100% illumination equal to numeric value 2048?

Thanks for you ear.

Joe

erm213
12-29-2011, 12:23 PM
The user interface uses 0 to 100% to identify illumination levels.

Is there a setting or configuration that tells Vixen what size of number to convert 100% into?

Is the default a byte (255)? Where can that be changed. Is there somewhere to tell Vixen 3 - make 100% illumination equal to numeric value 2048?

It is stored internally as a double, and is capped between 0 and 100 inclusive. The double provides for precision to 15 digits, so in this case 13 digits after the decimal. I would imagine this will be plenty for quite some time. The current effects may need to be changed to allow for more precision.

http://msdn.microsoft.com/en-us/library/678hzkk9.aspx

Thanks,

Erik

JHinkle
12-29-2011, 12:32 PM
Originally posted by erm213
It is stored internally as a double, and is capped between 0 and 100 inclusive. The double provides for precision to 15 digits, so in this case 13 digits after the decimal. I would imagine this will be plenty for quite some time. The current effects may need to be changed to allow for more precision.


I must not have worded my question correctly because your reply was based on internal storage - floating point double.

Somewhere in Vixen there is a translation from float to int and translates 100.0 float to the value provided to the Output module.

Is there a way to change Vixen from converting 100.0 into 255 to converting 100.0 into 2048?

Vixen probably uses a statement similar to ------> OutPutModuleDataValue = IllumLevel * MAX_OUTPUT_VALUE.

where OutPutModuleDataValue is a unsigned int, IllumLevel is your double, MAX_OUTPUT_VALUE is either a define or a configurable value - it appears to be defaulted to 255.

Can MAX_OUTPUT_VALUE be changed?

Thanks.

Joe

erm213
12-29-2011, 12:46 PM
I must not have worded my question correctly because your reply was based on internal storage - floating point double.

Somewhere in Vixen there is a translation from float to int and translates 100.0 float to the value provided to the Output module.

Is there a way to change Vixen from converting 100.0 into 255 to converting 100.0 into 2048?

Thanks.

Joe

The output module is doing the conversion. In the case of the Renard plugin, it receives an array of command. Each of these command is a set level command, and it gets the Level from the command. The Level type is essentially a wrapper for the double type. The Renard controller chooses to convert it to 8 bit, another output module can covert is any way it wants. Vixen is supplying a value between 0 and 100 inclusive to the output module.

Thanks,

Erik

JHinkle
12-29-2011, 01:18 PM
I'm so sorry to this forum - I've had my head up my A.......

Looking at the Output module code ... and running debug ...

Lighting.Monochrome.SetLevel.Level is your value of 100 (double).

Sorry - I had not actually set a break point and looked at the value - I thought it was returning the actual raw data. VS does not say that .Level was a Double or it would have been obvious.

I am very happy and apologize to the group for my stinky brown hair day.

Thanks

Joe

sallz0r
12-29-2011, 09:03 PM
The opinion that follows is what I currently understand by looking at the various controllers on the forum.

As you stated - As defined by usage today - your definition of a bus for 10 controllers having 16 channels is one message containing all 160 channels of data that is serially passed to the next controller until all 10 controllers have received the complete message.

I believe that mechanism was put into place based on RS232 criteria because RS232 is based on single node-to-node communication. So the bus concept used by DIY networks is one of each controller being required to pass the nessage down to the next controller. If you have 10 controllers on this type of bus, controller 10 is receiving its message with quite a bit of delay compared to controller 1.

True RS485 bus construction and usage, as used in industrial systems and automotive networks (CAN) - are not designed and operated like that.

The bus is defined as a half or full duplex network when multiple controllers attach. The controllers are all in parallel - not serially linked. The message frame that is transmitted on this bus contains a ID that is unique to a specific controller. There is no serial passing of the message. Every controllers receives the message frame at the same time and determines if the message is meant for it. If so, it saves the incoming message and processes it.

My request is for Vixen 3 to provide for the use of this true bus configuration.

If the capability was provided, the the Vixen 3 Output Module would then process 10 different controllers. The Output Module would know the controller's ID (based on Setup) - and create a message frame for that controller only. That message frame would then be sent out on the COM port specified for the BUS. You would have 10 different message frames being transmitted on the COM port bus.

I believe that's how it is already. As I understand it, I thought most of the current setups/controllers are designed with controllers being used on a bus, in parallel. Most of the setups I've seen use bus-like systems -- RS485, DMX, etc. -- to transmit data to a bunch of controllers at the same time. That's how the architecture is setup -- you don't configure individual controllers, you setup and configure..... 'streams', or 'protocols'. (If you're familiar with DMX 'universes', I believe it's the same sort of idea.)

If you wanted to do something like you describe, and send data to serialized controllers (or in a , then that would most likely have to be done entirely in the output module. It would be too specific to an instance or configuration to be able to suitable generalize and use the concepts in the application. Since an output module is able to have its own setup form, you could use that to allow the user to configure the different sub-controllers on a bus, how to split up the data, etc.

Or, I'm misunderstanding your intent again. Just as likely as anything else around here. :-)

WRT your question about level values, I think Erik covered that?

Hope that helps.

JHinkle
12-29-2011, 09:49 PM
Originally post by sallzOr
I believe that's how it is already. As I understand it, I thought most of the current setups/controllers are designed with controllers being used on a bus, in parallel. Most of the setups I've seen use bus-like systems -- RS485, DMX, etc. -- to transmit data to a bunch of controllers at the same time. That's how the architecture is setup -- you don't configure individual controllers, you setup and configure..... 'streams', or 'protocols'. (If you're familiar with DMX 'universes', I believe it's the same sort of idea.)

If you wanted to do something like you describe, and send data to serialized controllers (or in a , then that would most likely have to be done entirely in the output module. It would be too specific to an instance or configuration to be able to suitable generalize and use the concepts in the application. Since an output module is able to have its own setup form, you could use that to allow the user to configure the different sub-controllers on a bus, how to split up the data, etc.

Or, I'm misunderstanding your intent again. Just as likely as anything else around here. :-)


Unless I'm all wet - the Renard style of controllers are all serial - using the RS232 connection or the RS 485 --- they are not running a true parallel bus.

Take the 24 channel board.

RS485 data comes in and is fed to the first cpu's SCI receive pin. That cpu's SCI xmit pin is then fed into the second's cpu receive ... until cpu 3's xmit pin is fed into the second RS485 transceiver's out pin.

That is not a parallel design and results in slow transmission of data when multiple controllers are on a bus of this type.

That is probably why I have seen people only talk about having a couple of these boards on a COM bus and are running 3 to 4 to 5 etc COM buses in their system.

If people would use a parallel bus as I described - you could use a single COM bus and hang 30 controllers on it ... with controller 30 getting its complete message before controller 2 got its message doing the way most are doing it.

Look at the schematics - they are setup as serial.

I don't mean to step on toes - just clarify something.

As far as the request goes, I will do my processing in the current Output Module.


Thanks.

Joe

sallz0r
12-29-2011, 10:13 PM
Unless I'm all wet - the Renard style of controllers are all serial - using the RS232 connection or the RS 485 --- they are not running a true parallel bus.

Take the 24 channel board.

RS485 data comes in and is fed to the first cpu's SCI receive pin. That cpu's SCI xmit pin is then fed into the second's cpu receive ... until cpu 3's xmit pin is fed into the second RS485 transceiver's out pin.

Aah, my apologies, I didn't realize that. I haven't actually looked at specific boards/controllers for a while; I thought the renard just had everything on the bus in parallel. I must have been looking at a different control system a year or two ago when I was looking at others.



If people would use a parallel bus as I described - you could use a single COM bus and hang 30 controllers on it ... with controller 30 getting its complete message by the time controller 2 got its message doing the way most are doing it.

Yep, that's how I thought it was working. I didn't realize there were some setups that are different.

I'm not sure how the software could help fix that problem, though...... I understand that you request is to be able to somehow configure/specify individual controllers on a bus (so be able to set up 10 controllers of 16 channels each -- all using the same serial port, etc. -- rather than one output instance with 160 channels)..... but I'm not sure what it buys us. What would the benefit of it be?

One option -- if you wanted to set up 10 controllers on a single bus/stream, but keep them separate -- would be to actually instantiate 10 different module instances, one for each controller. Then you have the problem of a common serial port, but you could somehow share that between the instances (using a static handler that's in the output module class or something). I'm just throwing ideas out there, no idea if they're actually useful or not. :-)

I guess I can't see the benefit of having that configuration at a system level (rather that specific to the output module). It's currently designed in a bus-like system, and the serialized controller protocols just try to emulate that as best they can. Being able to configure that in software, though, doesn't solve the hardware problems with the serialized controllers.

You're certainly not stepping on any toes; forgive me if I've given the impression otherwise. I'm just trying to understand the motivation for the request, and what problem it's trying to solve, to see if there's another issue that's being masked, or a different way to approach it. :-)

JHinkle
12-29-2011, 10:44 PM
If a controller is designed to operate on a true RS485 parallel bus, then it only wants and cares about data it can process. Automotive CAN buses are RS485 in nature. There are 40+ modules all hanging on the same bus but each has an ID and the protocol is designed to have an ID in the beginning of the message frame. All controllers will read the first several bytes of the message until each has acquired the ID the message is destined for. Those controllers whose ID does not match - ignore the rest of the message. The key point is that the message has to contain a controller ID.

Now look at the way Vixen is designed and how the controllers that communicate through it are working. If you have Vixen setup where your channel count contains channels from multiple controllers - your network is a serial bus - very slow.

Given that ... I am assuming most everyone using Vixen (unless they are modifying the Output module to include controller IDs) are all operating in a serial fashion.

I am using a controller that is designed to hang on a parallel bus. Each controller has an ID and the message data it receives is just meant for it.

When I started to work in Vixen 3's output module, I followed the video (very good) on how to set it up. It did it exactly (serial bus fashion) just to make sure everything worked.

When I started to change the Setup design to fit a parallel bus - is where the Vixen architecture creates an issue.

Lets assume I want to use 3 - 24 channel controllers. They are all on the same COM port.

Following the design guidelines - each controller is defined in Vixen - each identifies a COM port.

In the output module, each controller would open and close it's own COM port (the same COM port) ... Not sure what Windows would do with 3 unique claims to the port. Might have a race condition when Controller 1 closes it's open COM port and controller 2 and 3 have not sent out their last message.

Is this a show stopper - not at all - it can all be worked around. The request was simply to have the option for a higher level of output hierarchy where a COM port is controlled by one entity and that entity has multiple controllers subordinate to it.

I'll stop talking about it now. Most all on the forum is using the serialized bus and will probably continue using it. I just wanted to point out some things that you might consider to take Vixen and the forum to a higher level of performance

People have to watch - just because their controller says its a DMX controller - does not mean its designed to operate in a true RS485 parallel environment.

Thanks again for your ear.

Joe Hinkle

Jrd
12-29-2011, 11:38 PM
Joe,
Are you aware of the Renard Start Address Firmware (http://www.doityourselfchristmas.com/wiki/index.php?title=Renard_Start_Address_Configuration _Guide)?

If I understand you correctly then all Renard hardware can be run in a parallel environment with the use of the start address, If you would like to keep the rest of the serial data going to the next controller before the first controller is done then make a simple splitter board or buy a splitter so the RS485 signal can go to the board and downstream at the same time.

And this doesn't require any new software in Vixen.

sallz0r
12-30-2011, 12:43 AM
If a controller is designed to operate on a true RS485 parallel bus, then it only wants and cares about data it can process. Automotive CAN buses are RS485 in nature. There are 40+ modules all hanging on the same bus but each has an ID and the protocol is designed to have an ID in the beginning of the message frame. All controllers will read the first several bytes of the message until each has acquired the ID the message is destined for. Those controllers whose ID does not match - ignore the rest of the message. The key point is that the message has to contain a controller ID.

Fair enough. But all that detail of protocol is something that should be encapsulated by the output module, obviously; it's not something that can be handled at a system architecture level.


Now look at the way Vixen is designed and how the controllers that communicate through it are working. If you have Vixen setup where your channel count contains channels from multiple controllers - your network is a serial bus - very slow.

I'll have to disagree with you there. I can't see how you made that conclusion? If I have a output module instance for a bus that has 160 channels on it, 10 boards x 16 channels per board, then the output module can get the data for those 160 channels and decide what to do with it. That's entirely dependent on the protocol. In the case of DMX and others, it might send all channel values every update period, and there's no addressing on anything on the bus: it just sends out 160 values, one after the other. In the case of other protocols (I'm thinking of my own custom system here), the output module might look at the values for the 160 channels it has, and compare against previous values to see which channels have changed, and sent out only commands to those boards to say "update channel <x> to value <y>". It can send only to specific controllers if the protocol supports it and it desires so, or it might send out all values and controllers ignore the values not for it, etc...

So I would disagree with your description of the current setup as a serial bus. It's up to the output module to decide how it wants to use it.



In the output module, each controller would open and close it's own COM port (the same COM port) ... Not sure what Windows would do with 3 unique claims to the port. Might have a race condition when Controller 1 closes it's open COM port and controller 2 and 3 have not sent out their last message.

Sure. That's what I was meaning before by maybe sharing the serial port in a static object in your class, so different module instances can share access to a single serial port. Not particularly elegant, but might do what you need if you really want to instantiate three separate controller instances that are sharing a single bus.

ErnieHorning
12-30-2011, 01:25 AM
We're still talking about controlling just Chrismas lights right?

rstehle
12-30-2011, 01:41 AM
We're still talking about controlling just Chrismas lights right?

That's kinda what I have been thinking for a while ...............

Mactayl
12-30-2011, 08:34 AM
We're still talking about controlling just Chrismas lights right?



That's kinda what I have been thinking for a while ...............

Same here.......

sadkisson
12-30-2011, 01:16 PM
I have multiple sound cards in my computer have tv connected computer speakers etc would be nice to have a function in vixen to select which audio to output sound like where this is headed great job

budude
12-30-2011, 02:53 PM
I have multiple sound cards in my computer have tv connected computer speakers etc would be nice to have a function in vixen to select which audio to output sound like where this is headed great job

I believe Vixen 2.x already has this - however - it does not seem to work with programs. I can run sequences OK but when I run a program of sequences it refuses to play out the headphone jack. It might be nice to allow multiple sound outputs if that is possible.

sallz0r
01-01-2012, 01:26 AM
We're still talking about controlling just Chrismas lights right?

Heh, yep. Just talking about it in more abstract terms. :-)

There *is* provision in the software to be able to control other things, but that just means we consider stuff in a more abstract manner. We're still talking about lights, though. :-)

(My apologies for the overly technical/in-depth discussion. I didn't realize it was getting like that. I wonder if it's worth splitting some of this off into new threads to make it more manageable? Or, heck, even a new sub-forum for 3.0 stuff to keep discussions contained?)

KC
01-01-2012, 01:38 AM
Lets assume I want to use 3 - 24 channel controllers. They are all on the same COM port.

Following the design guidelines - each controller is defined in Vixen - each identifies a COM port.

Yes and no. There isn't any UI in place to support what I'm about to say, but I figure an explanation is warranted nonetheless.

The intention, for controllers, is to try to mimic your physical hardware configuration. So for each controller you have, you define a controller instance. That doesn't differ from what you see right now. What there is support for, but you don't yet see (my fault, I didn't think it would be called for this early), is the ability to further mimic your hardware configuration by linking controllers that share a port to each other. The daisy-chained controllers imply an order of those controllers and any data going to those controllers goes through the port configured in the root controller.

It's assumed that a single output module has authority over a port and this is assumed because it's further assumed that if you have multiple controllers connected to that single port, they're all of the same type or at least handle the same format of data. This came about because some foresighted person, who is not me and I can't remember who and I'm sorry I can't properly credit or attribute them, a year or two back said "with Renards, you can...".

I don't know if this will address all scenarios, but it's a start.

JHinkle
01-01-2012, 02:16 PM
Thanks KC - that is exactly what I was hoping for.

Since its not out yet - but in the structure - is Vixen going to call the output module for each controller at each time slot or only once (containing all data for all linked controllers) meaning I would have to parse it for each controller.

It would be nice to have each linked controller called separately - just makes the code more structured.

Thanks again.

Joe Hinkle

KC
01-01-2012, 08:26 PM
Each controller in the chain will be called, in order, to update its state the same as if they weren't linked. The only difference is that the data ends up going out the single output module of the chain's root controller. The output module is made aware of the index of the controller within the chain so that it can format the data appropriately.

sallz0r
01-02-2012, 12:16 AM
Aah, right. My apologies, I didn't realize that functionality was in there at all. So that sounds like a solution to everyone's problem. :-)

My apologies for the confusing discussion.

aussiephil
01-03-2012, 08:24 AM
Ernie: yep i'm certainly still talking christmas lights. I for one (and most heading into large RGB displays) have some quite high end requirements around output channels and considering what Vixen25 can already do in the E131/DMX space have a high expectation on Vixen3.
Pending actual output modules for E131 and DMX what I have seen is exciting and very very promising.

All my other thoughts and written comments around objects etc are just to give the brilliant programmers ideas that may be able to be incorporated into the architecture so that there is room to grow into that space.

Personally if Vixen3 can have E131 output, and the current UI for sequencing then that would likely do my show for 2012.

So on that note, KC, Sallz0r or any of the team, any news on E131 or DMX output modules.

Oh one other comment, seriously we shouldn't limit the sequencing software to cater for old hardware.... if Vixen3 requires a quad core CPU to drive say 5000 channels then go and buy a new PC. We as enthusiasts spend thousands on lights and controllers then complain when the software fails to run on the four year old dual core with 512Mb RAM, XP alone runs best with 1GB plus and 16GB seems to be the new machine standard!
The above machine specs not directed at anyone.

sallz0r
01-03-2012, 08:46 AM
All my other thoughts and written comments around objects etc are just to give the brilliant programmers ideas that may be able to be incorporated into the architecture so that there is room to grow into that space.

And in that regard, the discussion has been very helpful, with everyone's comments and feedback (just on the general flow of the software, what they want to be able to do with it, etc.)


Personally if Vixen3 can have E131 output, and the current UI for sequencing then that would likely do my show for 2012.

That's what we're hoping. Well, we havn't discussed it, so I'll leave it up to KC to decide (don't want to put words in his mouth!), but given what we've achieved in the last year, and given the direction and solid framework underneath, I think we'll be able to achieve a lot more in the coming year. Personally, I would hope that a sizable portion of the community (20%? 50%? 80%?) would be able to use 3.0 for their 2012 display.



So on that note, KC, Sallz0r or any of the team, any news on E131 or DMX output modules.

I know Erik was working on them, but not sure what the status was (if he needed someone to test, etc.) Unfortunately, December's usually a write off for all of us -- as I'm sure you well know! -- given everyone's own personal responsibility with their displays, and then the family/xmas/holiday commitments. Yikes!


Oh one other comment, seriously we shouldn't limit the sequencing software to cater for old hardware.... if Vixen3 requires a quad core CPU to drive say 5000 channels then go and buy a new PC. We as enthusiasts spend thousands on lights and controllers then complain when the software fails to run on the four year old dual core with 512Mb RAM, XP alone runs best with 1GB plus and 16GB seems to be the new machine standard!

Oh, by all means, we're not doing things to cater for older hardware explicitly; ie. we're saying "we won't write feature <x> because it would require high-end machines to use." However, the performance of <feature x> on old hardware might be indicative of how machine intensive it is, and that can give us a bit of a guide as to how well it's written (or not!).

For example, if we write <x>, and find that the software is limited to 50 channels on an old machine, and 500 on a newer machine, then we might realize we need to optimize, or do things to improve performance. After that, we might find the old machine can run 400 channels, and a newer one can run 4000.

So we're not targeting any machine, or *trying* to do anything in particular to cater for old machines; however, good desgin and well-written code allows us to get every last inch out of a machine, which might mean a 20th channel for someone's old Pentium 2, or a 20,000th channel for someone's core i7. :-)

Having said that, I'm almost sure that 3.x will be more intensive for a given number of channels than 2.x was with the same number. I have no testing or figures to back that up, just a gut feeling. I could be completely wrong. :-)

aussiephil
01-03-2012, 07:04 PM
And in that regard, the discussion has been very helpful, with everyone's comments and feedback (just on the general flow of the software, what they want to be able to do with it, etc.)


Thanks



That's what we're hoping. Well, we havn't discussed it, so I'll leave it up to KC to decide (don't want to put words in his mouth!), but given what we've achieved in the last year, and given the direction and solid framework underneath, I think we'll be able to achieve a lot more in the coming year. Personally, I would hope that a sizable portion of the community (20%? 50%? 80%?) would be able to use 3.0 for their 2012 display.


Get's on hands and knees to KC........................ with Renard, DMX and E131 modules i would expect based on what i've seen so far and the show videos you posted that most could use it, the change in paradym will hold many back that love the grid but a bunch of how to videos will help there.




I know Erik was working on them, but not sure what the status was (if he needed someone to test, etc.) Unfortunately, December's usually a write off for all of us -- as I'm sure you well know! -- given everyone's own personal responsibility with their displays, and then the family/xmas/holiday commitments. Yikes!


Oh yes, end of the year, shows etc yep, spent 28 nights sitting outside meeting greeting and thanking people for donations (oh and drinking the odd beer) so fully understand. Erik if you are reading this is there anything i can do to help.
Actually installed C# last night and about to work my way through the video tutorials on coding modules so might get up to speed, been years since i played with dotnet code :)




Having said that, I'm almost sure that 3.x will be more intensive for a given number of channels than 2.x was with the same number. I have no testing or figures to back that up, just a gut feeling. I could be completely wrong. :-)

Considering all the work being done to walk the relationship trees it's got to be more intensive, but processing horsepower is cheap these days :)

Cheers and all the best in 2012...................... (now back to work :) )

chilloutdocdoc
01-03-2012, 08:41 PM
I agree AussiePhil. With a bit of a learning curve. I am excited to see/use 3.0 for my 2012 show.

I did create a Enttec Open DMX output (got bored for my week off work and whipped it up.) Details are http://doityourselfchristmas.com/forums/showthread.php?18904-Vixen-3-0-Enttec-Open-DMX-Output-Module&p=190530

As for the optimization, and speed of computers. I think there is a balance between supporting features and needing a new computer. If my old P4 won't cut it... then I guess I'll need to get a faster computer. It ran a full universe on my I3 laptop without too much hassle, just a few things that will surely get cleaned up in time.

jpb
01-06-2012, 09:02 PM
Is there a way to get the latest Beta version? I am playing around with things and I am coming across things that have been listed as resolved in the bug tracker. I don't want to start reporting things that have already been fixed.

Jon.
BTW. Fantastic work on the efforts so far, it is looking great.

DynamoBen
01-06-2012, 09:09 PM
Is there a way to get the latest Beta version?

There isn't a new build available yet, we will post when there is.

sallz0r
01-07-2012, 09:33 AM
Is there a way to get the latest Beta version?

Not yet. We're hoping to eventually set up something that builds more regularly and automatically, but haven't gotten there yet.


I am playing around with things and I am coming across things that have been listed as resolved in the bug tracker. I don't want to start reporting things that have already been fixed.

That's a fair enough concern. If it's clearly the same problem, then it has been fixed and should be in the next version. If you're not sure if it's the same problem as one that's been fixed, feel free to comment on the ticket to clarify: "hey, I see that this bug describes when you do <x>, I'm doing <y> and seeing the same thing. Is that fixed as well?" and I'll try to make sure to clarify, or if not put it in a new ticket.

(even if you make duplicates, that's no problem. It's no hassle to close with a comment/link to the old ticket that it's a duplicate of.)

You make a good point, though! Thanks for you help testing it out. :-)

chilloutdocdoc
01-07-2012, 11:41 AM
This may seem like overkill for such a small thing.. But what about a repository just for releases? Everybody would be up to date automatically.

Con's might outweigh the pros though...

BF210
01-08-2012, 03:12 AM
at the moment, the 'Level' command simply specifies a floating point number from 0 to 100, to represent intensity.

I haven't been following too closely, (short of spare minutes this year) but I missed something in the 'Level' discussion. There is a way to send a specific value to the target channel/device, isn't there? Such as setting DMX universe 1, channel 213 to exactly 27, because 26 and 28 do Something Completely Different? I'm fine with 'Level' being a percentage, but some things need to be sent precisely as defined.

sallz0r
01-08-2012, 09:12 AM
Such as setting DMX universe 1, channel 213 to exactly 27, because 26 and 28 do Something Completely Different? I'm fine with 'Level' being a percentage, but some things need to be sent precisely as defined.

That's where the paradigm shift happens between how things worked in 2.x and in 3.x.

If you're doing <something else completely different> with the effects, then you don't want lighting effects. You want animatronics effects. Or Movement effects. Or <whatever category you're working with> effects. Let me try to clarify it a bit.....

When you sequence things in 3.x, you're supposed to be capturing the _intent_ of what you want to happen. Effects are the tools to do this. You can use an effect to describe things like, "OK, I want <this> group of lights to chase around in a loop". You're not talking about specific command levels, you're not talking about physical controller values, you're talking in abstract light levels -- 100% down to 0%. Then, once they get executed, passed through to the output module, do they actually get converted to hard values that should be used that are specific to that control system (eg. DMX being from 0-255, from memory?)

Now, I know you're saying that isn't what you're after: you want to be able to set channel 213 to level 27. But I'm sure there's a bigger reason for that; what's the *intent* of setting that channel to that level? I'm guessing it's to do something else, non-lighting related. (for example, the prop listening on that channel might be for animatronics, and value "27" might mean 'move the arm up'.) If so, then you don't want to use a 'set lighting level' effect (which is what the 'set level' effect actually is) -- you want to use some other (not-yet-written) effect, which controls animatronics. In that case, the effect captures the *intent* of what happens -- 'move this channel in direction <x> for <y> seconds'. It's in the translation down to the low-level commands that it somehow gets converted into the magical value '27', since it's been configured to have special significance for that reason.

So that's one of the major changes between 2.x and 3.x -- the ability to capture the intent of a display or sequence. Instead of having to reverse engineer specific values to mean something very particular, we're able to avoid the 'working backwards' and make sure things represent what should actually happens. Makes life a lot easier in general, just takes a bit to get used to the shift in thinking. :-)

(Interestingly, it also makes it a lot easier to work with some things when it's a lot more abstract; for example, I would forsee that sharing sequences would be HEAPS easier in future. If someone writes a sequence describing what *should* happen, rather than "here's a bunch of commands to send to a controller to make it happen", then someone else can just take all those 'shoulds' and put them on their own stuff. A chase around Bob's megatree, which is 64 strings, and RGB LEDs, on DMX controllers? Translates fine to Jim's megatree, which is 40 strings, on renard controllers, and single color. ..... but I'm getting ahead of myself. :-) )

Aurbo99
01-08-2012, 02:56 PM
KC

My display is down for the year, the radio is silent and the display system has been shut down..

YOUR MOVE my friend, :naughty:

(not to pressure you of course!)

Matt_Edwards
01-08-2012, 05:36 PM
Now, I know you're saying that isn't what you're after: you want to be able to set channel 213 to level 27. But I'm sure there's a bigger reason for that; what's the *intent* of setting that channel to that level? I'm guessing it's to do something else, non-lighting related. (for example, the prop listening on that channel might be for animatronics, and value "27" might mean 'move the arm up'.) If so, then you don't want to use a 'set lighting level' effect (which is what the 'set level' effect actually is) -- you want to use some other (not-yet-written) effect, which controls animatronics. In that case, the effect captures the *intent* of what happens -- 'move this channel in direction <x> for <y> seconds'. It's in the translation down to the low-level commands that it somehow gets converted into the magical value '27', since it's been configured to have special significance for that reason.


Another example I am interested in: I would like to build in more smarts into controllers that are used for very specific tasks. falling Snow tubes are one example. the DMX channel defined the speed of the falling snow, not the light intensity. Or a strobe would have the strobe rate.

My understanding is all of these will be possible with an appropriate animatronics module. Correct?