Home› AMX User Forum› NetLinx Studio

Level back and forth

Jeff LockyearJeff Lockyear Posts: 147
in NetLinx Studio
I've been trying to find a better way program two-way level control, by which I mean that the same bargraph can send a level and display the feedback value.

I have it working with a Vantage lighting system, and when I started I found it possible to put the lighting system into a loop. The feedback would be a little behind the level out, so the bargraph would change to the feedback value under your finger, and then send that value out again, etc etc.

I got around it by disabling feedback from the lighting system based on the push of the bargraph, and then updating it on the release, but it seems like a clunky solution.

Anyone have any alternatives?

Jeff

Comments

  • jjamesjjames Posts: 2,908
    Jeff Lockyear wrote: »
    I've been trying to find a better way program two-way level control, by which I mean that the same bargraph can send a level and display the feedback value.

    I have it working with a Vantage lighting system, and when I started I found it possible to put the lighting system into a loop. The feedback would be a little behind the level out, so the bargraph would change to the feedback value under your finger, and then send that value out again, etc etc.

    I got around it by disabling feedback from the lighting system based on the push of the bargraph, and then updating it on the release, but it seems like a clunky solution.

    Anyone have any alternatives?

    Jeff
    Would using $P fix your problem?
  • Jeff LockyearJeff Lockyear Posts: 147
    That's an excellent question jjames....

    $P provides a text version of the bargraph level, right? I'm not sure how that would help. Could you elaborate? Thanks :)

    Jeff
  • jjamesjjames Posts: 2,908
    I was just taking a stab - at first it seemed that you were looking for a way to get the current level's display on the level without code, so that's why I suggested $P.

    I guess I just don't understand exactly the issue or what you're trying to do. Are you trying to do 100%-real-time levels?
  • mpullinmpullin Posts: 949
    We use two bargraphs in this type of situation: an invisible one on top for control and a display only underneath it for feedback.
  • Jeff LockyearJeff Lockyear Posts: 147
    Real-time levels are exactly what I'm trying to do. So I want the bargaph to display the current lighting level, while using the same bargraph to send a new level to the lighting system as long as a finger's dragging it.

    And the issue I'm having is (I believe) that the level going out is always going to be a bit higher than the level coming in from the lighting system; and that's caused the lights to loop and flash between the new level and the lower feedback level. So while defeating feedback while dragging seems to have worked, it seems a clunky workaround.
  • jjamesjjames Posts: 2,908
    Well, the level going out SHOULD be the level of the lights, correct?

    If you tell Vantage to discretely go to 20%, then 21%, then 22, then 23, etc. - it will go 20-21-22-23, etc. If you tell it to go 25, 40, 45, 21, 90 wouldn't it do it? I think the problem is the perception of real time based on how long the lights actually take to get to said percent. Either way - Vantage *SHOULD* end up on the last sent level. The problem you will probably have is how quickly it can receive the strings . . .

    For volume bargraphs (not all that different than lighting bargraphs), I keep track of the level myself and what is display is what was sent out last. Of course, when entering the page - you may want to query it's value.
  • Jeff LockyearJeff Lockyear Posts: 147
    Thanks for the ideas! I'm keeping track of what the level should be (like you suggested) and waiting until the level_event from the panel is over before feeding back the light level from the Vantage system, and so far (at least on my desk) it's working fine.

    Cheers.
  • viningvining Posts: 4,368
    mpullin wrote: »
    We use two bargraphs in this type of situation: an invisible one on top for control and a display only underneath it for feedback.
    x2.

    Also add a channel port and channel to your invisible "touching" bargraph and set a tracking channel or var on push, unset on release. Use this to prove your level event form the bargraph. If no push, no level change so that panels falling off line don't send a level value of zero to your lighting system.
  • jcereckejcerecke Posts: 40
    I was wondering something similar but with modules.

    Got an amp, polling it in case someone changes volume on front panel. On setting the volume of the amp, it also responds with the current level of the volume which is the same as polling response so...

    Send level to vdvAmp > vdvAmp sends volume change code to dvAmp > dvAmp responds with new volume > Send level with new volume to vdvAmp level for feedback.... does this then trigger the level event for vdvAmp again?

    I think that makes sense.
  • viningvining Posts: 4,368
    if the level values are the same the master should break what otherwise could be an inifinite loop. Since the master tracks levels as long as your math is correct and value y was sent by the master to xDev it won't send value y to xDev again as it comes back around. In theory it should only make 1 complete revolution as long as the value of y remains the same.

    I would still change the code to break that loop.
  • a_riot42a_riot42 Posts: 1,624
    jcerecke wrote: »
    I was wondering something similar but with modules.

    Got an amp, polling it in case someone changes volume on front panel. On setting the volume of the amp, it also responds with the current level of the volume which is the same as polling response so...

    Send level to vdvAmp > vdvAmp sends volume change code to dvAmp > dvAmp responds with new volume > Send level with new volume to vdvAmp level for feedback.... does this then trigger the level event for vdvAmp again?

    I think that makes sense.

    As Vining says, a level_event won't get triggered if its already at that level, which it will be since you sent the value to the virtual when you parsed it from the amp. Same thing with channel events which can sometimes be annoying when you want to update a panel coming online but that's fine. I see no reason to change working code that is engineered correctly like Vining would, but I'm lazy.
    Paul
  • viningvining Posts: 4,368
    a_riot42 wrote: »
    As Vining says, a level_event won't get triggered if its already at that level, which it will be since you sent the value to the virtual when you parsed it from the amp. Same thing with channel events which can sometimes be annoying when you want to update a panel coming online but that's fine. I see no reason to change working code that is engineered correctly like Vining would, but I'm lazy.
    Paul
    It's only engineered correctly if he took the way the master works into account when writing the code. If he didn't he just got lucky. Besides sending a level to a dev and then having that dev's level event send a level back to the originating dev to trigger that dev's level event which then tries to send that same level value back again doesn't sound like it's engineered properly. One mistake in the code and you could blow speakers, get all sort of wierd feedback, etc. I know I've done it before. :)

    I have no problem sending a level to a dev in one direction on every pass of the mainline since I know it willonly be sent once but the back and forth action seems wrong, they shouldn't trigger events that way. Each direction should be single ended.
  • a_riot42a_riot42 Posts: 1,624
    vining wrote: »
    It's only engineered correctly if he took the way the master works into account when writing the code. If he didn't he just got lucky.

    I'm giving him the benefit of the doubt that he programmed it thinking it should work that way but wanted to be sure and asked here. Either way, I don't change good code regardless of whether skill or luck was the method used to create it.
    vining wrote: »
    Besides sending a level to a dev and then having that dev's level event send a level back to the originating dev to trigger that dev's level event which then tries to send that same level value back again doesn't sound like it's engineered properly. One mistake in the code and you could blow speakers, get all sort of wierd feedback, etc. I know I've done it before. :)

    I don't think that's what he is doing. My understanding of the event table is this:

    dvTP --> vdvDev --> dvDev --> vdvDev --> dvTP.

    I'm not seeing anything wrong with this design at all. Perhaps you are doing something other than this and having problems.
    vining wrote: »
    One mistake in the code and you could blow speakers, get all sort of wierd feedback, etc. I know I've done it before. :)

    Any mistake in any code can have deleterious effects on things. That's why I try not to make any.
    vining wrote: »
    I have no problem sending a level to a dev in one direction on every pass of the mainline since I know it willonly be sent once but the back and forth action seems wrong, they shouldn't trigger events that way. Each direction should be single ended.

    Mainline can introduce timing issues with events which could possibly cause problems, and I wonder if that is what you were seeing.
    Paul
  • viningvining Posts: 4,368
    jcerecke wrote: »
    Send level to vdvAmp > vdvAmp sends volume change code to dvAmp > dvAmp responds with new volume > Send level with new volume to vdvAmp level for feedback.... does this then trigger the level event for vdvAmp again?

    I think that makes sense.
    Sounds to me he was asking if his vDev sends to his Dev and his Dev sends back to the vDev then the vDev would send back to the Dev. It sounds like the way his code is written it could and if not for the master tracking levels it would never end but since it does it should only make one complete loop. The loop as described makes no sense to me but if it works it works and I guess having all your feedback in the mainline also works so we should leave that be too. Hey if it ain't broke why fix which I believe is what you're saying.

    FYI, what I was reffrering to with my level looping issues was a long time ago an don't recall what the circumstances were and as far as my comment on level feedback in DEF_PROG that was just to illustrate that since the master tracks levels like it does channels it's not he end of the world or for that matter the end of the master. It's not the greatest thing to do but it is doable with out any significant ill affects on a typical system. I personally don't like to do it as a general rule but I'm not going to put someone down who does. Hopefully in time they'll change but if not god bless them anyway.
Sign In or Register to comment.