DiyLightAnimation
Software => Light Show Pro => Topic started by: mitch09 on January 21, 2011,
-
Anyone know how or the best way to set up a SString controller in LightShow Pro? Should I just create a new one and assign a protocol? Do I need to create a new controller for each SS Controller I use? I notice when I try to create a new controller it asks how many channels. Will this be dependent on each SScontroller I have?
Any help is appreciated.
Ryan
-
The logic way will be :
1°) Declare the SString output ( new plugin made by David), not yet available officially...
2°) Create a new RGB controller in the librairy...
I'm not so far from reallity, i think...
-
LSP 1.9 already has the ss output in it. there are many ways to do it I guess but one way is to load a RGB controller type with the number of channels you need and then setup the ss output plugin to it.
RJ
-
uh, 1.9? last release on the LSP is LightShowPro_v1_8_10326_1055. Is 1.9 a version in early test/beta?
-
I guess I wasn't too clear on what I am trying to figure out. I can add a RGB controller with Pixelnet/SString output, but am not sure about the other options. I have added a few pictures to hopefully help clarify my questions. If I want my Sstrings to behave as one strand of lights that I can change from Red-->White-->Green, I assume I set it up like it is (see pics). The problem is I am not sure how to change the color within one Track in LSP.
Now if I wanted to use all the nodes individually, I think I've got that figured out.
Thanks in advance,
Ryan
-
If you program the controller to string mode yes you would only give it 3 channels like that.
Yes I goofed the rev number it is in there at this point.
RJ
-
Great thread.
Just curious, If you were to set the channels to say 128 (instead of 1) ... does that take it from string mode to pixel mode? And can the SS Controller then be set to 131, so the first 3 are r,g,b (only), then the other 128 are in pixel mode? (assuming you program the strings for the 131) ...
-
If you set the number to 128 you would actually have 384 channels. If you set it to 43 you would have 129 rgb channels.
Am I misunderstanding your 128 number?
-
I guess I wasn't too clear on what I am trying to figure out. I can add a RGB controller with Pixelnet/SString output, but am not sure about the other options. I have added a few pictures to hopefully help clarify my questions. If I want my Sstrings to behave as one strand of lights that I can change from Red-->White-->Green, I assume I set it up like it is (see pics). The problem is I am not sure how to change the color within one Track in LSP.
Now if I wanted to use all the nodes individually, I think I've got that figured out.
Thanks in advance,
Ryan
Hi Ryan,
That is the correct setup. To get the color you want just put whatever effect in the grid and the color picker will pop up as LSP knows it is an RGB controller. Dont use the RGB tool that is designed for non RGB controllers.
Hope that helps
Mike
-
If you set the number to 128 you would actually have 384 channels. If you set it to 43 you would have 129 rgb channels.
Am I misunderstanding your 128 number?
Thats right, sorry ... I knew it multiplied stuff by 3 for RGB.
So the string mode vs. pixel mode ... thats all set using RJ' SS setup software, right?
So if you set the strings into string mode there, then you set up as 3 channels in LSP, so 3x3=9 RGB channels total.
And if you set the strings up as 128 nodes, then it show up as 128x3 channels in LSP.
Correct?
-
If you set the number to 128 you would actually have 384 channels. If you set it to 43 you would have 129 rgb channels.
Am I misunderstanding your 128 number?
Thats right, sorry ... I knew it multiplied stuff by 3 for RGB.
So the string mode vs. pixel mode ... thats all set using RJ' SS setup software, right?
Correct
So if you set the strings into string mode there, then you set up as 3 channels in LSP, so 3x3=9 RGB channels total.
You would set it to 1 channel that would be 1x3 or 3 RGB tracks, that would control the entire string.
And if you set the strings up as 128 nodes, then it shows up as 128x3 channels in LSP.
Correct?
You would set the LSP controller up as 128 channels which is 128X3 RGB tracks. But IMHO, that is a lot to handle for the PS, Hub and SSC
-
You would set the LSP controller up as 128 channels which is 128X3 RGB tracks. But IMHO, that is a lot to handle for the PS, Hub and SSC
But correct me I'm wrong, many people are doing 8x128 or 16x80 for a megatree with these, so one string of 128 nodes (x3 channels) does seem like much. I know to program it all, yeah, PITA ... but thats where LSP comes in, right?
I know you need a good 50A to 70A 12v single rail ATX power supply, but the hub is designed for 16 outputs and daisy chain to more.
-
I was wondering how LSP handles the channels for SS (Smart String) Hybrid mode.
Hybrid mode is a combination of String and Node mode so its (# of Nodes * 3) + 3
example: 60 Nodes = 183 Channels (60*3)+3
Cheers
Rick R.
-
Hi Rick,
Configure the controller(s) for 61 channels. (183 RGB tracks).
Since the SS uses tracks 1-3 to control the string then the effects in channel 1 (tracks 1-3) would apply to the entire string.
The other channels would then control the individual nodes.
Edit: You could also configure 2 controllers to do the same thing if that were easier to understand
controller 1 1 channel 3 tracks starting with channel 1
controller 2 60 channels 180 tracks starting with channel 2
Make sense?
Edit 2: The channel numbers above would be adjusted depending on previous sscs and their position in the universe.
Mike
-
I think Hybrid mode refers to an ability in the programming of the smart strings, whereby you have the best of both worlds: string mode (i.e. red for all, green for all and blue for all ... all nodes on the string) and pixel mode (rgb for each pixel). So if you had a 128 pixel S String, in hybrid mode 1-3 would be the string mode operation of R,G,B (for all pixels) so 1=red for all, 2=green for all, 3=blue for all ... and 4-131 would be the RGB for each of the 128 pixels so pixel 1 would be 4,5,6 (4=r,5=g,b=6) and pixel 2 would be 7,8,9 (7=r,8=g,9=b), and so on.
Again, talking about programming the smart strings, then you would see in LSP as 131 channels x3, so 393 total.
That my understanding of Hybrid mode (coudl be a tad off) ... but I about died of excitement when I watched RJ' video on it last night ... and he was showing both modes and the prorgamming, etc.
-
I think Hybrid mode refers to an ability in the programming of the smart strings, whereby you have the best of both worlds: string mode (i.e. red for all, green for all and blue for all ... all nodes on the string) and pixel mode (rgb for each pixel). So if you had a 128 pixel S String, in hybrid mode 1-3 would be the string mode operation of R,G,B (for all pixels) so 1=red for all, 2=green for all, 3=blue for all ... and 4-131 would be the RGB for each of the 128 pixels so pixel 1 would be 4,5,6 (4=r,5=g,b=6) and pixel 2 would be 7,8,9 (7=r,8=g,9=b), and so on.
Again, talking about programming the smart strings, then you would see in LSP as 131 channels x3, so 393 total.
That my understanding of Hybrid mode (coudl be a tad off) ... but I about died of excitement when I watched RJ' video on it last night ... and he was showing both modes and the prorgamming, etc.
i think we are saying the same thing, just using different numbers ;D Ricks example used 60 nodes which is what I responded to. Please feel free to correct me if i am mistaken
-
I saw a great video on using Light Show Pro with CCRs. Should be similar with smart strings....
Check this out if you haven't seen it. It may help.
http://www.vimeo.com/11414852
Light Show Pro looks like kick-arse software...as soon as I get a lynx together, I'm going to demo it and possibly buy it.
-
I saw a great video on using Light Show Pro with CCRs. Should be similar with smart strings....
Check this out if you haven't seen it. It may help.
http://www.vimeo.com/11414852
Light Show Pro looks like kick-arse software...as soon as I get a lynx together, I'm going to demo it and possibly buy it.
it is similar but I don't think CCrs have the hybrid or the entire string mode. Again, please correct me if i am wrong
-
I was going to do tihs myself, but I figure mmulvenna would be the better choice since he probably is the resident expert on LSP . Could you make up a nice video on doing "smart string" and put in on vimeo. I think it would answer a BUNCH of questions, epsecially if you take into account what has been posted in this thread. I think doing that would go a long ways to focusing the questions people have and allowing the LSP coders to understand the user's goals.
-
Doing it now........ Video is uploading will post link when completed
-
Here is a link to the LSP forum where the video is located. This is how I would configure them in LSP. I don't have hardware to test this with yet, so these instructions could change slightly. Please feel free to correct or question any observations I have made in the video. <fp. ???
Please remember, the SSC mode is configured using RJ's configuration software not by LSP.
http://www.lightshowpro.com//showthread.php?1134-Video-Demos The video will be the last one listed. Feel free to watch any of the other videos in the link.
-
Thanks for that video. I think I can answer my question more focused now.
You said to start at channel 1. Could we not start at channel one in order to "sub-divide" them so I can apply them more deftly to layers and whole sections. I like the fact that I can, LSP, collapse a section of nodes and apply affects as a whole (string mode) or tweak it in node mode.
Having them all under one big controller would make this much more tedius. I have attached example of what I mean. Thanks in advance.
-
Yes you can do that. What you are really doing is just building controllers in the software so the channels are easier to manage. You just need to make sure that the correct channel numbers are assigned.
You can start the channels with any number you want as long as it matches the SSC configuration.
So you could manage 1 ssc with as many controllers as you would like to build. You could have an ssc that has 50 (150 RGB) nodes or build 10 different controllers of 5(15 RGB) nodes each to handle it.
You just need to be careful not to overlap channel numbers. You can actually do this if you want but it would get pretty confusing to manage let alone make sure that subsequent channels are configured properly.
Hope that helps and that my old feeble brain is properly understanding your question. ???
-
It is the answer I was hoping for. I think this question will be important to many people. Just hope it works out that way with actual hardware.
-
If you set the number to 128 you would actually have 384 channels. If you set it to 43 you would have 129 rgb channels.
Am I misunderstanding your 128 number?
So the string mode vs. pixel mode ... thats all set using RJ' SS setup software, right?
So if you set the strings into string mode there, then you set up as 3 channels in LSP, so 3x3=9 RGB channels total.
And if you set the strings up as 128 nodes, then it show up as 128x3 channels in LSP.
Correct?
Correct me if I’m wrong but the major reason for the macros/string mode is to accommodate software that doesn’t easily handle huge channel counts, cases where people don’t need the individual pixel level control or that have issues with the amount of data required to update a large quantity of pixels. In the “ideal” world, the controller doesn’t need to do macros as that functionality is performed in the software. So, if you setup LSP so that a 128 pixel SS was a 128 channel RGB controller (384 DMX channels) and you wanted the entire string to be blue, you could just select the entire controller in the grid and select “ON” and it will prompt you for the color you want and you would select blue – then the entire string will turn blue. With the macro mode, you would just setup a single three channel RGB controller in LSP and set it to the three RGB DMX addresses on the macro-enabled SS controller and you’d again do the same thing. The difference is, that with the latter, you completely lose the ability to control all the pixels individually and can only address them as a single color (RGB). So, since LSP isn’t restricted in its ability to handle large channel counts and PixelNet will handle 2,048 channels, I can’t imagine why the macro mode would be useful in that situation.
-
Thanks for that video. I think I can answer my question more focused now.
You said to start at channel 1. Could we not start at channel one in order to "sub-divide" them so I can apply them more deftly to layers and whole sections. I like the fact that I can, LSP, collapse a section of nodes and apply affects as a whole (string mode) or tweak it in node mode.
Having them all under one big controller would make this much more tedious. I have attached example of what I mean. Thanks in advance.
What mike showed in the video (http://vimeo.com/19409331) with the 51 pixels (153 channels) wouldn’t be generally necessary in LSP and if you ever use something like transitions to auto-sequence, it will cause havoc if you are applying a transition to an entire controller (which is often the case). I’d personally recommend setting it up in the second method shown by Mike – you get complete control of ALL the pixels and if you want to apply an effect to the entire string all at once (say, fade entire string red to green) you can collopase the controller and then apply the effect to the complete controller. This way you have the ease of setting effects to hundreds of channels with one effect OR you can control each individual pixel (manually or via Transitions). When used with LSP, I’d recommend against string mode.
-
I don't want, eventually, to have 4000+ nodes under a single controller in LSP. There is no way, mentally, for me to wrap my head around that. That would be like deleting the LE controller and just putting down a DMX universe and call it a day. Conversely, it would be like saying splitting up a LE into four seperate 4 channel controllers isn't of value either (think mini trrees).
I thiink there might be a balance in the middle though. Right now LSP is flat in how it lists controllers. However, because it can collapse and because I can asign nodes indiviudally, it gives it a bit more power to segment things. However, What happens if LSP had a way of effecitvely making sub-sections off the main controller...sorta like a directory strucutre:
Top Controller
- Mini Trees
- Mini Tree #1
- Pixel 1
- Pixel 2
- ....
- Pixel n
- Mini Tree #2
- Pixel 1
- Pixel 2
- ....
- Pixel n
- ......
- Mega Tree
- Spine #1
- Pixel 1
- Pixel 2
- ....
- Pixel n
- Spine #2
- Pixel 1
- Pixel 2
- ....
- Pixel n
- ....
- House
- Houe Roof
- Section 1
- Seciton 2
- ....
- House Windows
- window 1
- Window 2
- Window 3
- ....
- Garage
- Left
- Top
- Right
- .....
All I know is I like the fact I segement pixels however I want. I like the fact I can assignment multiple segments to a single layer and apply effects. However, I do see your point of keeping all nodes under one controller but would find that impossible to handle over the longer term.
-
Thanks for that video. I think I can answer my question more focused now.
You said to start at channel 1. Could we not start at channel one in order to "sub-divide" them so I can apply them more deftly to layers and whole sections. I like the fact that I can, LSP, collapse a section of nodes and apply affects as a whole (string mode) or tweak it in node mode.
Having them all under one big controller would make this much more tedious. I have attached example of what I mean. Thanks in advance.
What mike showed in the video (http://vimeo.com/19409331) with the 51 pixels (153 channels) wouldn’t be generally necessary in LSP and if you ever use something like transitions to auto-sequence, it will cause havoc if you are applying a transition to an entire controller (which is often the case). I’d personally recommend setting it up in the second method shown by Mike – you get complete control of ALL the pixels and if you want to apply an effect to the entire string all at once (say, fade entire string red to green) you can collopase the controller and then apply the effect to the complete controller. This way you have the ease of setting effects to hundreds of channels with one effect OR you can control each individual pixel (manually or via Transitions). When used with LSP, I’d recommend against string mode.
I agree with David that is is not necessary to use String or HYBRID mode in LSP if you intend to use node control. I also agree with Trepidati0n in the fact that is is easier to understand if you separate the controllers into logical units rather than one large physical unit and LSP can accommodate what David and Trepidati0n are saying.
As I said in post number 22 "So you could manage 1 ssc with as many controllers as you would like to build. You could have an ssc that has 50 (150 RGB) nodes or build 10 different controllers of 5(15 RGB) nodes each to handle it."
-
Having them all under one big controller would make this much more tedious.
I'd agree with Mike - I'd make the "controllers" in LSP (which could or could not releate to physical SS controllers) never larger than a single element or larger than a single DMX universe. This will make creating layers and transitions easier.
Here is another really useful tip if you are planning to use transitions - Make sure that your display photo used for the visualizer is perpendicular and completely centered and is low res (320x240). Be sure you watch http://www.vimeo.com/11414852 from 1:00 to 1:30 on how to define your pixels as single-pixel per channel section. Also make sure that you properly measure out the physical strings as to where they will appear on your actual house. Getting "close" will result in poor results when used with the transitions.
-
So I could take a single 128 node SS (call it SS#1), and say I determine that I can install them onto a mini megatree as up1,down1,up2,down2 segments.
In that example, I could lay them up in LSP SS1-up1 (1-32 RGB channels)., SS1-down1 (33-64 RGB channels), SS1-up2, and SS1-down2 ... and then LSP could
treat each of those segment (SS controller segments) like individual 32 channel/node RGB strings (96 channels) ?
-
So I could take a single 128 node SS (call it SS#1), and say I determine that I can install them onto a mini megatree as up1,down1,up2,down2 segments.
In that example, I could lay them up in LSP SS1-up1 (1-32 RGB channels)., SS1-down1 (33-64 RGB channels), SS1-up2, and SS1-down2 ... and then LSP could
treat each of those segment (SS controller segments) like individual 32 channel/node RGB strings (96 channels) ?
Yep, with the correction below pretty cool huh.... or create 4 different layers and do the same thing with only one controller defined
controller 1 would be 1-96
controller2 would be 97-192 etc
Making a video to show it and will post later
-
So I could take a single 128 node SS (call it SS#1), and say I determine that I can install them onto a mini megatree as up1,down1,up2,down2 segments.
In that example, I could lay them up in LSP SS1-up1 (1-32 RGB channels)., SS1-down1 (33-64 RGB channels), SS1-up2, and SS1-down2 ... and then LSP could
treat each of those segment (SS controller segments) like individual 32 channel/node RGB strings (96 channels) ?
That is a possible method that would work fine – to break the “physical” SS controller into four LSP controllers. Yes… here is the math at the DMX channel level:
Controller 1: 1-96 DMX Channels
Controller 2: 97-192 DMX Channels
Controller 3: 193-288 DMX Channels
Controller 4: 289-384 DMX Channels
On issue you should be aware of with a solution like that (unrelated to LSP) is that when you come back down from the second string, if you have more than ~3.5 gap between them at the bottom, you’ll lose a few pixels. So, within LSP you would need to cut out, say, 3-12 channels between the 2nd and 3rd string. I’d think losing four pixels (12 DMX channels) would work best since then you’d maintain your even count of pixels going up and down each string (124 total, 31 pixels per vertical run). Also setting each “string” of the megatree on a separate controller would make manual programming easier.
Of course you could also splice in a jumper.
-
Thanks, I'm really loving those possibilities. Loosing 4 pixels would be fine.
-
Video is uploading will post soon in about 40 minutes when it is uploaded.
-
Here is the video http://vimeo.com/19545594 that I made using the current release of LightSHowPro.
It shows 1 physiclal smart string controller of 128 nodes configured as 4 logical controllers in LSP using the example given by taybrynn in his post above
nodes 1-32 are installed as "Upstring 1"
nodes 33-64 are installed as "Downstring 1 "
nodes 64-96 are installed as "Upstring 2"
nodes 97-128 are installed as "Downstring 2"
The example shows how you only need to configure the SSC as "node based" and not "hybrid" or "String Base".
LSP will handle the "Hybrid" of "String base" as shown in the video
Hope that helps some.
-
Thank you!! That is great. Thanks for show how easy it is to do in LSP.
-
Thank you!! That is great. Thanks for show how easy it is to do in LSP.
Anytime, always glad to help. As I am retired I have lots of time to make videos like that so feel free to ask.
Also make sure to check out the videos that are posted in The Tips and Tricks in LSP which should help reduce with the learning curve.
-
Here is the video http://vimeo.com/19545594 that I made using the current release of LightSHowPro.
You know, I now see a second reason why to break them into separate controllers - as shown in the video, it goes:
Bottom to Top 1: 1-96 DMX channels
Top to Bottom 1: 97-192 DMX channels
Bottom to Top 2: 193-288 DMX channels
Top to bottom 2: 289-384 DMX channels
Be aware that in the video it shows in the visualizer that "bottom to top 1" is being drawn top to bottom as is "Bottom to top 2". You will need to match the direction of the controller output (which matters in pixels) in the “real world” to what is reflected in the visualizer. Using this up, then down solution, while it reduces controllers, it will make manual sequencing a bit more complicated (unless some hardware macro was created or change in sequencing software occurred). So, say you want to make your entire tree go from red to green, top to bottom and you were not using transitions, you would need to know that string 1 bottom to top would be sequenced backwards – that is it would start out (on the timing grid) with green fading into red but on the string 1 top to bottom, you would need to have red fading into green since it would be going from the top down.
With transitions, assuming you’ve drawn your pixels in the proper direction that matches the physical DMX channel layout, is really a no-brainer but if you are sequencing manually, it would require some mental gymnastics to keep all that in mind. I’d argue that this is where auto-sequencing really comes to the rescue but for those manually manipulating these it would seem the sequencing software could have a “reverse” channel order (not sure if LSP has this…heck, I wouldn’t be surprised if it already does…). Of course most pixel controllers have a reverse but it applies to the entire string or output, not part-way through the string - so pixels 1-32 (up) are channels 1-96 and pixels 33-64 (down) are channels 192-97.
-
Great observations. It would be nice if each controller could just reverse the (top to bottom) channel order shown/used (for a controller), so that channels 1->32 could also be listed as 32->1 . Then as long as you broke up the string into 4 controller and flipped a couple of them, it would all work out (via. the software) .
Also, I noticed that when I collapse each of those 4 controllers, that I would think I could apply effects to those 4, like I could to 4 different channels. But in LSP, its not working that way. When I try to say create a chase across those 4 as the controller level, it just put the chase into the first channels of the first controller, not the range of 4 controllers selected. Very unpredictable behavior.
Again, when I collapse the 4 controllers, to show as 4 lines (like channel) ... and while if I put an on event on all 4, it works for all 4 ... but I try so do a solid color chase across all four (like spinning the green on a megatree, across 4 sections) ... it doesn't work the same way, just puts chases into the first (n) channels on the first controller, even though they are all collapsed.
-
Here is the video http://vimeo.com/19545594 that I made using the current release of LightSHowPro.
You know, I now see a second reason why to break them into separate controllers - as shown in the video, it goes:
Bottom to Top 1: 1-96 DMX channels
Top to Bottom 1: 97-192 DMX channels
Bottom to Top 2: 193-288 DMX channels
Top to bottom 2: 289-384 DMX channels
Be aware that in the video it shows in the visualizer that "bottom to top 1" is being drawn top to bottom as is "Bottom to top 2". You will need to match the direction of the controller output (which matters in pixels) in the “real world” to what is reflected in the visualizer. Using this up, then down solution, while it reduces controllers, it will make manual sequencing a bit more complicated (unless some hardware macro was created or change in sequencing software occurred). So, say you want to make your entire tree go from red to green, top to bottom and you were not using transitions, you would need to know that string 1 bottom to top would be sequenced backwards – that is it would start out (on the timing grid) with green fading into red but on the string 1 top to bottom, you would need to have red fading into green since it would be going from the top down.
With transitions, assuming you’ve drawn your pixels in the proper direction that matches the physical DMX channel layout, is really a no-brainer but if you are sequencing manually, it would require some mental gymnastics to keep all that in mind. I’d argue that this is where auto-sequencing really comes to the rescue but for those manually manipulating these it would seem the sequencing software could have a “reverse” channel order (not sure if LSP has this…heck, I wouldn’t be surprised if it already does…). Of course most pixel controllers have a reverse but it applies to the entire string or output, not part-way through the string - so pixels 1-32 (up) are channels 1-96 and pixels 33-64 (down) are channels 192-97.
David is absolutely correct and I apologize for not pointing that out. All you need to do is check the "Reverse order" check box when you draw the element.
-
Also, I noticed that when I collapse each of those 4 controllers, that I would think I could apply effects to those 4, like I could to 4 different channels. But in LSP, its not working that way. When I try to say create a chase across those 4 as the controller level, it just put the chase into the first channels of the first controller, not the range of 4 controllers selected. Very unpredictable behavior.
Again, when I collapse the 4 controllers, to show as 4 lines (like channel) ... and while if I put an on event on all 4, it works for all 4 ... but I try so do a solid color chase across all four (like spinning the green on a megatree, across 4 sections) ... it doesn't work the same way, just puts chases into the first (n) channels on the first controller, even though they are all collapsed.
Are you trying what Mike did in his video (http://vimeo.com/19545594) starting at 6:00? You shouldn’t have any problem applying effects to the entire controller. Now if you apply a chase across four collapsed controllers, it is not going to make the chase occur across all four controllers – this is where and object oriented sequencing application would apply (such as with transitions). So, this isn’t unpredictable behavior – it’s just not the behavior are expecting from it – I’m sure it will predictable do that each time you apply the effect. Now if you apply a fade across all four collapsed controllers, you will be fine since there is no controller to controller relationship like there is with a chase.
-
Great observations. It would be nice if each controller could just reverse the (top to bottom) channel order shown/used (for a controller), so that channels 1->32 could also be listed as 32->1 . Then as long as you broke up the string into 4 controller and flipped a couple of them, it would all work out (via. the software) .
Also, I noticed that when I collapse each of those 4 controllers, that I would think I could apply effects to those 4, like I could to 4 different channels. But in LSP, its not working that way. When I try to say create a chase across those 4 as the controller level, it just put the chase into the first channels of the first controller, not the range of 4 controllers selected. Very unpredictable behavior.
Again, when I collapse the 4 controllers, to show as 4 lines (like channel) ... and while if I put an on event on all 4, it works for all 4 ... but I try so do a solid color chase across all four (like spinning the green on a megatree, across 4 sections) ... it doesn't work the same way, just puts chases into the first (n) channels on the first controller, even though they are all collapsed.
David is absolutely correct in his post about the viz drawing and I apologize for not pointing that out. All you need to do is check the "Reverse order" check box when you draw the element..
Also here is a video doing a chase across multiple collapsed controllers. http://vimeo.com/19569511 The video is using very small channel counts so it could be that your chase issues is related to the number of channels.
EDIT: Just tried the chase with 4 128 channel controllers, collapsed them,put a chase across the controllers and it work the same as the above video shows. Not sure why it is not working for you? Can you make a video of the process?
-
Again, I really think that if I apply an ON, or FADE-UP, or FADE-DOWN across four collapsed controllers ... I don't see why its different when I do a CHAS across those four collapsed controllers. The reason I collapsed them is because I wanted a different level of control over them.
If I wanted the chase to just go into the first 4 channels of the first collapsed controller (as its doing), I would have expanded it and selected that range and done the chase there. Since I collapsed it and selected the 4 collapsed controllers, I find it illogical that it would chase only into the First 4 channel of controller1, when doing the same on other effects would apply to all channels within all four collapsed controllers.
I just think if we are limited to object oriented operations on all four collapsed controllers, then don't let me do a chase on the four, and produce such illogical results.
-
Again, I really think that if I apply an ON, or FADE-UP, or FADE-DOWN across four collapsed controllers ... I don't see why its different when I do a CHAS across those four collapsed controllers. The reason I collapsed them is because I wanted a different level of control over them.
If I wanted the chase to just go into the first 4 channels of the first collapsed controller (as its doing), I would have expanded it and selected that range and done the chase there. Since I collapsed it and selected the 4 collapsed controllers, I find it illogical that it would chase only into the First 4 channel of controller1, when doing the same on other effects would apply to all channels within all four collapsed controllers.
I just think if we are limited to object oriented operations on all four collapsed controllers, then don't let me do a chase on the four, and produce such illogical results.
Sorry but my old brain still does understand as In the video It appears to me to be operating correctly. What am I missing that it is not working for you?
If I do an on or fade in the first "x" channels across 3 collapsed controllers, that efffect appears in all "x" channels in each controller, correct?
If I do the same thing with a chase across "x" channels across 4 collapsed controllers, the chase goes into the first " x" channels of controller 1 skips the remaining channels on controller 1, then proceeds to controller 2 picking up the chase where controller 1 left off.
Is it that you want to chase "string mode" from controller 1, to 2, to 3 and so on? Maybe that is what I am missing and if so, then that is one reason for using a "hybrid". You could then put the hybrid channels on a layer and chase across them.
Am I just rambling or does this make sense?
-
Sorry but my old brain still does understand as In the video It appears to me to be operating correctly. What am I missing that it is not working for you?
If I do an on or fade in the first "x" channels across 3 collapsed controllers, that effect appears in all "x" channels in each controller, correct? YES, CORRECT, you FADE on the collapsed channel, and all channels in the collapsed controllers will fade exactly the same (like a 32 RGB channel paste into each of the four collapsed controllers)
If I do the same thing with a chase across "x" channels across 4 collapsed controllers, the chase goes into the first " x" channels of controller 1 skips the remaining channels on controller 1, then proceeds to controller 2 picking up the chase where controller 1 left off. Again, I'm thinking I'm working at the collapsed level now, so anything I do should apply as if these were just 4 RGB channels, regardless of how many RGB channels are underneath each collapsed controller.
Is it that you want to chase "string mode" from controller 1, to 2, to 3 and so on? Maybe that is what I am missing and if so, then that is one reason for using a "hybrid". You could then put the hybrid channels on a layer and chase across them. YES, thats what I want to do. To me, partitioning the SS CNTLR into 4 controllers in LSP (thank you very much, BTW) allows these channels to be treated like 4 RGB channels (when collapsed). So chasing into the first (x) channels isn't consistent with how I'd expect it to work, since when collapsed, I'm working at a totally different level of abstraction, then when they are expanded.
Am I just rambling or does this make sense? no, you make perfect sense. I just think that I'm trying to convey that by collapsing these controllers, yes, I expect them to work differently, because I want to sequence them just like 4 RGB channels, not try to read my mind and work one way during a chase and another way for a FADE or ON ... which already works as expected. Thats why I'm saying its inconsistent. Hopefully you can understand what I'm seeking here.
-
I understand what you are saying so if the ssc is setup as HYBRID and then the hybrid channels are assigned to a layer(s) you can then do a chase as you are describing.
I am not sure how the software would determine on a collapsed controller if you wanted to treat the effect(s) as a node based or string based effect, I think that is why you would need to do the hybrid. When you do a on or fade on a collapsed controller it is actually do that effect on each node. I will forward to David at LSP to see if perhaps he can come up with anything.
Thanks for putting up with the antics of an old man as I finally understand what you are saying. <fp. <fp. <fp.
-
Again, I really think that if I apply an ON, or FADE-UP, or FADE-DOWN across four collapsed controllers ... I don't see why its different when I do a CHAS across those four collapsed controllers. The reason I collapsed them is because I wanted a different level of control over them.
If I wanted the chase to just go into the first 4 channels of the first collapsed controller (as its doing), I would have expanded it and selected that range and done the chase there. Since I collapsed it and selected the 4 collapsed controllers, I find it illogical that it would chase only into the First 4 channel of controller1, when doing the same on other effects would apply to all channels within all four collapsed controllers.
I just think if we are limited to object oriented operations on all four collapsed controllers, then don't let me do a chase on the four, and produce such illogical results.
It’s different because LSP isn’t design that way. Now, what you are attempting to do would mostly work with layers and transitions. Where you are at is right at the edge of why we need better object oriented sequencing – that chase doesn’t understand any channels outside of that controller. So, the chase effect in LSP isn’t really OO. I think you’ll find in LSP 2.0 this issue resolved and it will work as you’d expect.
-
I think for what I was trying to do ... it could most easily be accomplished using the 3 hybrid RGB channels (instead of collapsed controllers), mainly because (as mentioned above) LSP handles CHASE and WAVE differently than the other effects.
So in some of the LSP videos, where the (selling) point is made that collapsing (the controller), then applying an effect across all channels (in the collapsed controller) at once ... is a great thing (which I agree) ... should have some asterisks (***) ... where *** = does not necessarily work the same way for CHASE, since it just generates (n) ON events, one per interval ... till the x-axis range selected is satisfied. That what I really meant about inconsistent behavior.
Again, I think I'm probably just unhappy with the Chase more than I have a real issue here. The way chase works across collapsed now seems consistent with how it works un-collapsed. I would say that it seems like illogical results when done from a collapsed controller perspective and perhaps (the chase) could/should be disabled for use on a collapsed controller.
The wave effect actually works fairly well on the collapsed controllers, but the CHASE really doesn't, but thats just because of the simple way that is works in general.
The chase is really the most poorly implemented effect in LSP currently (**). For software that is normally
far more advanced (in LSP) vs. the others ... the Chase is the one effect, which in its current form (1.8.x) is
actually significantly less advanced than how LOR S2 or Vixen does it. LOR S2 finally got it right in its recent version of the chase, IMHO ... but thats just my opinion. I also think Vixen has some great ways apply a chase which should also be considering for copying.
**Ok, its just behind the undo/redo problem, in terms of severity., as the wild and limited undo, and lack of redo ... is the #1 worst LSP thing currently.
Thanks to all for explaining to me, and I believe I really am starting to understand LSP a lot better. The object oriented stuff just blows me away. The basic features, seem like they got fast-tracked and therefore lack the polish I would have expected. Got those fixed, redo/undo, get rid of the lag, and stabilize ... and nothing will compare.
I'm being told the forthcoming version 2.x will be much better, so I'm hopeful.
-
Dmoore, I agree ... my problem is that I want LSP to do an OO chase ... and it can't.
I also think when I select an effect range, that thats the exact range it should create the effect within, not just close.
I'm also looking for stability and refinement of core capabilities, not more ipad integration.
Any idea when the new version of LSP (2.x ?) might be coming out?
-
Dmoore, I agree ... my problem is that I want LSP to do an OO chase ... and it can't.
I also think when I select an effect range, that thats the exact range it should create the effect within, not just close.
I'm also looking for stability and refinement of core capabilities, not more ipad integration.
Any idea when the new version of LSP (2.x ?) might be coming out?
Hi,
As I don't use LOR or VIXEN, from a user standpoint can you be more detailed on what they can do in a chanse that LSP cant.
Can you elaborate on the "I also think when I select an effect range, that thats the exact range it should create the effect within, not just close." statement. Are you referring to just creating and effect or using a pattern/copy paste?
Also I agree, with the undo/redo and that they need to be fixed.
-
I'll create a video of this and then you'll see what I'm talking about.
The difference is in the implementation of the chase. The LOR implementation
is exact. I've also tried it in Vixen and its also exact. In LSP its a swag.