Home› AMX User Forum› AMX General Discussion
Options

2D device arrays

MLaletasMLaletas Posts: 226
in AMX General Discussion
I'm working on a particular project and within my current framework it made sense to use this. It works but just curious if anyone else has used this as well. If so how did you handle that data event? For now I have them listed out separately within the first dimension.

Comments

  • Options
    nickmnickm Posts: 152
    That is the correct method of doing what you've described.
  • Options
    ericmedleyericmedley Posts: 4,177
    I've actually been in situations where I was 4 and 5 dimensions. It's okay to do this if you can keep what the dimensions mean in your head and it's documented in code well. But, in all these cases I tended to do button_events for a specific cell then used a button_stack of those cells for the added array dimensions. Then, in the event, I'd relate the upper dimensions via button.input.device or .channel or however I was differentiating the array cells out and do the math to get the dimension id.

    One thing to keep in mind when doing this is this kind of code can create a large number of button_events depending upon how large the array dimensions are. A single button event cannot have more than a few thousand ids. If you go beyond the limit, it will sometimes still compile and all that. It just won't work and if you're not careful, you can spend a lot of time debugging code that is not 'wrong' but still doesn't 'work'
  • Options
    ericmedleyericmedley Posts: 4,177
    Also,
    Depending upon the size/scope of your whole project and the size of your eventual button array(s) this might be a good candidate for button_event,0 (the catchall)
  • Options
    MLaletasMLaletas Posts: 226
    Cool just wanted to see if there were any ill effects, honestly I havent seen anyone use that convention before. Below is kinda what I did as an example. As far as button events I think the size is 4000. I use 0 sometimes (usually for generic sources) and button arrays for everything else.
    DEFINE_CONSTANT

DEV vdvTest[5][] =
{
{
33001
,33002
}
,
{
33011
,33012
}
...ETC...
}

DATA_EVENT[vdvTest[1]]
{
ONLINE:
{
STACK_VAR INTEGER lvLastDevice
lvLastDevice = GET_LAST( vdvTest[1] )
}
}
  • Options
    viningvining Posts: 4,368
    ericmedley wrote: »
    Also,
    Depending upon the size/scope of your whole project and the size of your eventual button array(s) this might be a good candidate for button_event,0 (the catchall)

    And the catch all doesn't have the 4k channel limit and I think uses the resources of just one channel. A little foggy on this but those are my recolllections.
  • Options
    ericmedleyericmedley Posts: 4,177
    vining wrote: »

    And the catch all doesn't have the 4k channel limit and I think uses the resources of just one channel. A little foggy on this but those are my recolllections.

    This is one of those discussion we all had back in the olden dayse of yore' that I was fascinated me. it's one of those examples of good code (from a readability standpoint) didn't always translate into good code (from a processor efficiency) stand point.

    I don't enough about the under-the-hood aspect of how NX/NI processors handle events, how it stacks them and the processing of them. I have written entire systems on just one catch-all button event. It made for a pretty hefty stack of logic to traverse to get to your actual button event code. But, it did seem to be pretty zippy. I personally don't mind having many button events, however.
  • Options
    viningvining Posts: 4,368
    ericmedley wrote: »

    This is one of those discussion we all had back in the olden dayse of yore' that I was fascinated me. it's one of those examples of good code (from a readability standpoint) didn't always translate into good code (from a processor efficiency) stand point.

    I don't enough about the under-the-hood aspect of how NX/NI processors handle events, how it stacks them and the processing of them. I have written entire systems on just one catch-all button event. It made for a pretty hefty stack of logic to traverse to get to your actual button event code. But, it did seem to be pretty zippy. I personally don't mind having many button events, however.

    I remember when the catch all was introduced and I was running tests to get familar with it. I was shocked when it would catch channels above 4000 so I kept trying and I think it went up to 65535 and then I thought that would be a terrible resouce hog. Fortunately one of the engineers chimed in and said is just uses a single channel resource and very processor friendly. Thise were the good old days.
  • Options
    MLaletasMLaletas Posts: 226
    Maybe I should use the catch all more often. This is a tangent of the original post but anything to have these "philosophical" discussions that I miss, and honestly I do try to attempt to restart with some of my posts.

    Anyway I usually only do a catchall with generic devices, source devices like STB's, BD's, etc... Codec's, DSP's, VoIP I have setup separate button event array of similar functions (dialer, content, phone book, camera control). Seems like the general opinion is the catchall is actually less resource hungry even though it's a little harder to read because of the additional logic needed. Although if you still use arrays or channels with certain ranges to clean things up.
  • Options
    viningvining Posts: 4,368
    When I use the catch all I just use select active to isolate groups of channels and then use a function call to process further. That keeps things neat and tidy so I end up with one button event but then I have functions to organize my code into logical groups of operarion which keeps me from having a single button event 4000 lines long.
Sign In or Register to comment.