Home AMX User Forum AMXForums Archive Threads AMX Hardware AutoPatch Forum

New Precis Code

Anyone tried it yet, I see it was just updated. Wondering if it is good enough to stop working on my own homebrewed version yet...

Comments

  • Spire_JeffSpire_Jeff Posts: 1,917
    It appears that the module only has GUI updates. It seems to be the same old comm module that I had very little success with.

    On a seperate note, some features I would like to see added to the module:

    Doorbell/paging support. This should be a command that switches all outputs marked for Paging/Doorbell to the designated input at a predetermined vol level. Then another command that reverts to the original status/vol of each output.

    Support for the DSP and preferably 3 or so preset DSP configurations.

    Stable support for grouping of zones to allow relative volume raising and input switching via a single virtual zone. (also DSP settings)

    I think that ends my list of suggestions. Keep in mind that my opinions are based on working with the PRECIS LT unit.


    Jeff

    P.S.
    I have the first two almost completely functional, it's just a little messier than I like right now. The last one, I vaguely recall running into problems in having the precis LT work the way I interpreted the BCS commands should function.
  • Rod NRod N Posts: 28
    I've just finished an instal with a Precis LT. Had some initial RS232 timing hiccups ie multiple string sends.. but now seems as solid as. Love the EQ and gain control ability.
  • DHawthorneDHawthorne Posts: 4,584
    Sometimes modules are updated without changing the version tag in the file name - matter of fact, I have yet to see one that wasn't 1_0_0. Check the date and file size, it might be different after all.
  • I am programing my 1st PrecisLT 18x18 w/DSP and I am having a hard time with the feedback for volume, gain, treble, bass and balance levels. Any ideas. I had to give up on the AMX Java module. It doesn't have the DSP functionality, and as mentioned before the feedback is broken. I think that AMX needs to design a specific module to the PrecisLT w/DSP, which supports whole house audio, proprer feedback and multiple TPs. As of right now, I am able to switch, ramp up/down volume and I am looking for any help with the feedback part. For whole house distribution, usually, I have a map of the house and a pop up page to handle each zone. I also have an all areas page that shows all zones volume bargraphs and preset volume ranges (10% to 100%). It was a breeze to do that on the AS16, but on the PrecisLT w/DSP is a different game. Attached is what I have so far. Any help will be very appreciated.
  • Well, I guess the switching is easy to implement in a one way module for the PrecisLT w/DSP:

    SEND_STRING dvSwitch,"'DL2O1T'" //Disconnect
    SEND_STRING dvSwitch,"'CL2I1O1T'" //Connect
    SEND_STRING dvSwitch,"'CL2O1VS+T'" //Vol Up
    SEND_STRING dvSwitch,"'CL2O1VS-T'" //Vol Dn
    SEND_STRING dvSwitch,"'CL2O1VMT'" //Mute
    SEND_STRING dvSwitch,"'CL2O1VUT'" //Mute Off

    My problem is implementing the DATA_EVENT to work for the volume and gain.

    How are you guys capturing the volumes from the PrecisLT and connecting them to bargraphs in a touch panel?
    Do you query for all volumes at startup? How are you handling the DB ranges?
    Can the PrecisLT w/DSP handle simultaneous volume ramping on different zones?

    Since this piece will be mostly used in a Whole House Audio, I think AMX should create a specific module to support the DSP functions as well multiple TPs. Should I consider something else Vaux, ADA or knox? Any help on the volume feedback will be very appreciated.

    Sincerely,

    Ricardo
  • alexanboalexanbo Posts: 282
    As a last resort you could always store the volume level in your program and use the absolute volume commands to send the volume level to the level the program thinks it should be at.
  • How do I capture the volume levels from the PrecisLT w/DSP? Any ideas?

    Thanks,

    Ricardo
  • AutoPatch Group needs to monitor this Forum!!

    Greetings to the AutoPatch Group. You should monitor this forum. There are great questions here, and now since you are under the AMX roof, We (the users, installers, designers, programmers and salesmen) want more then just a great performing product. We need a great product from an integration standpoint.

    Oh yeah, any chance you can increase the speed of the RS-232 on Precis Products? Its to easy to flood the port when ramping the volume. Thanks
  • trobertstroberts Posts: 228
    Any luck with module v1.2.0?

    One thing extremely lacking in this module is the ability to control and see feedback for bass and treble control. Does anyone have any complete working module or demo programming for the Precis w/ DSP that they would like to share?
  • jjamesjjames Posts: 2,908
    alexanbo wrote:
    As a last resort you could always store the volume level in your program and use the absolute volume commands to send the volume level to the level the program thinks it should be at.
    Last resort? That should be the *first* resort. When it comes to volume, if you can tell the device - no matter what it is - what volume to go to, then that should be the first approach.

    Why wait to know what the volume is? To me, a generic volume +/- command is basically saying, "device, will you please increase your volume for me, and when you're finished also tell me what volume you're at?" C'mon guys, we're in the CONTROL business; control the thing, and TELL it what volume to go to. This eliminates you "waiting and wondering" what the volume is.

    Now, if the device doesn't allow you to do that, and isn't reliable enough to accept a bombardment of discrete volume commands, then it's not worth controlling. I've been using a code block I received from a friend about a year ago that's controlling the Precis - and let me tell you - it's perfect. I've never run into a problem with it. I'm actually very surprised there are problems with the module.
  • DHawthorneDHawthorne Posts: 4,584
    jjames wrote:
    Last resort? That should be the *first* resort. When it comes to volume, if you can tell the device - no matter what it is - what volume to go to, then that should be the first approach.

    Why wait to know what the volume is? To me, a generic volume +/- command is basically saying, "device, will you please increase your volume for me, and when you're finished also tell me what volume you're at?" C'mon guys, we're in the CONTROL business; control the thing, and TELL it what volume to go to. This eliminates you "waiting and wondering" what the volume is.

    Now, if the device doesn't allow you to do that, and isn't reliable enough to accept a bombardment of discrete volume commands, then it's not worth controlling. I've been using a code block I received from a friend about a year ago that's controlling the Precis - and let me tell you - it's perfect. I've never run into a problem with it. I'm actually very surprised there are problems with the module.

    Well and good until someone walks up to the device and turns the volume to 80%, and you panels says it's still at 30%. Your point is valid if you are the only one controlling it, but that is not always the case, and for those exceptions, you need to have real feedback.
  • jjamesjjames Posts: 2,908
    They're not supposed to do that, and instructed not to - that's the point of the systems we sell, right? But the moment they hit volume or or down, all is good again, and it goes back down to where it's supposed to be. Plus - it's a moot point when we're dealing with the Precis - there isn't a way to control volume or switching from the front.

    I dunno - I guess real feedback on volume should only as a back up IMHO. I guess it just boils down to style and how you want the system to work.
  • jjames wrote:
    They're not supposed to do that, and instructed not to - that's the point of the systems we sell, right?

    I always assume that the user will operate by its front panel anything that can be reached. Who are we to tell them not to? Do we expect them to RTFM? I certainly don't.

    This means, for instance, that you can assume nothing about the state of IR controlled gear.

    Most serial controlled gear will give you state change feedback so you can just change it back if you really want to!
  • DHawthorneDHawthorne Posts: 4,584
    As a general rule, I always prefer real feedback as opposed to "this is what I told it to do" feedback. I suppose in the end it's strictly philosophical, but I want to know what the equipment is actually doing, not what I told it. In a perfect world, those are the same things, and I certainly strive to make it so; but there are simply unavoidable circumstances when it can't be.

    I also never tell a customer, "do it the way I told you, or it won't work right." I consider it my job to accommodate them, not the other way around. If they want to poke at the front panel manually, it's their business ... and when that happens, I need real feedback.

    Don't get me wrong: I'm not trying to come down on anyone else's way of doing things; I'm just offering another point of view. Take it or leave it, whatever works for you and your company is what works for you.
  • I usually do both. Tell it what level to go to and keep track of that, then use feedback to make sure I'm where I think I am.
  • viningvining Posts: 4,368
    troberts wrote:
    Does anyone have any complete working module or demo programming for the Precis w/ DSP that they would like to share?
    I recently wrote a module but unfortunately I got side tracked when I was about to start the DSP. It would only take me a day or so to complete but I don't know when I'll get that day.


    jjames wrote:
    Why wait to know what the volume is?
    It is the preferred method of control to have the controlled device respond with its state and not simply assume our command have been acted upon becasue we said so. That is what seperates us from the crowd.

    The Precise w/ DSP has no problem responding fast enough for almost instant volume feedback and my feedback bargraph are pretty smooth. The problem I think most people have is when they try to increment or decrement the volume cuz you then have to poll or query the level but why do that when you can send absolute levels. Increment and decrement in you code and send that as an absolute value and the Precis will respond (echo) that value in its response immediately. No waiting, no querying, no polling. It works great!

    I maintain mini bargraphs for each output as well as a larger bargraph for my currently selected and they all update fine using this method.
  • flcusatflcusat Posts: 309
    vining wrote:

    I maintain mini bargraphs for each output as well as a larger bargraph for my currently selected and they all update fine using this method.

    That's a cool interface Vining.
  • the8thstthe8thst Posts: 470
    Any progress on the DSP side of the module?
    I would love to be able to set the EQ from an 8400 instead of dealing with a laptop and 232 direct to the matrix and I really don't have to time to write the module from scratch (I wish I could give back to the community more, but I'm only a newb programmer with a limited amount of time).

    Thanks.
  • GregGreg Posts: 13
    My one annoyance with Autopatch is that it doesn't like getting commands too quickly. If you don't pace out commands by .5s a piece then it starts ignoring things. That makes it a real pain to do large switches on startup or calling "presets" which route certain inputs to specific outputs. (In the feedback you'll see commands gets cancelled by the 'X' command) Has anyone found some work around for that? I just queue all my AP commands and send one out every half second. Unfortunately for a video wall I did that means you're in for an 8 second wait to call certain layouts.
  • jjamesjjames Posts: 2,908
    Greg wrote: »
    My one annoyance with Autopatch is that it doesn't like getting commands too quickly. If you don't pace out commands by .5s a piece then it starts ignoring things. That makes it a real pain to do large switches on startup or calling "presets" which route certain inputs to specific outputs. (In the feedback you'll see commands gets cancelled by the 'X' command) Has anyone found some work around for that? I just queue all my AP commands and send one out every half second. Unfortunately for a video wall I did that means you're in for an 8 second wait to call certain layouts.

    I've never experienced that problem. The way the code I use works is that it doesn't send another command out until the response has a "T". Use a busy flag or a timed wait to send out the commands, then whenever you see the "T" come in from the device, turn off the flag or cancel the wait and send the next command.
Sign In or Register to comment.