Home AMX User Forum NetLinx Studio

Newbie code help

I am trying to write some code to the 25 favorite channels that appear on the touch panel. The device is an IR device. Any suggestions on how to handle the that task without writing 25 lines of executable code?

Comments

  • TonyAngeloTonyAngelo Posts: 315
    BUTTON_EVENT[vdvFavorites,0]
    {
        PUSH:
        {
    	SEND_COMMAND vdvCable[GET_LAST(vdvFavorites)],"'XCH ',ITOA(BUTTON.INPUT.CHANNEL)"
        }
    }
    
    

    Where vdvFavorites is a TP array and vdvCable is a cable device array.

    You will also need to configure the XCH command in the cable box Data_Event.
  • a_riot42a_riot42 Posts: 1,624
    TonyAngelo wrote: »
    BUTTON_EVENT[vdvFavorites,0]
    {
        PUSH:
        {
    	SEND_COMMAND vdvCable[GET_LAST(vdvFavorites)],"'XCH ',ITOA(BUTTON.INPUT.CHANNEL)"
        }
    }
    
    

    Where vdvFavorites is a TP array and vdvCable is a cable device array.

    You will also need to configure the XCH command in the cable box Data_Event.

    That button event will get called for every button press from any of the touch panels regardless of whether its a fav or not. Any non-fav channel will get sent to the cable device as well. Is that really what you want?

    I tend to do something like this:
    button_event[dvAllUIs, iFavs[1]]
    {
      push:
      {
        stack_var integer iChan, ui
        stack_var char sChan[3]
    
        ui = get_last(dvAllUIs)
        iChan = get_last(iFavs[1])
        sChan = itoa(iFavs[2][iChan])
        send_command dvUISources[ui], "'XCH ',sChan"
    		
      }
    }
    

    Where iFavs is a 2 dimensional mapping of channel numbers to stations favs.
  • TonyAngeloTonyAngelo Posts: 315
    a_riot42 wrote: »
    That button event will get called for every button press from any of the touch panels regardless of whether its a fav or not. Any non-fav channel will get sent to the cable device as well. Is that really what you want?

    I put the favs on their own TP port and assign the TP button to the fav number. The only buttons that are on this port are favorite buttons. You only assign buttons to the favorites you want. You want to change the favorites you only have to change the TP file not the code. I don't see any downside.
  • a_riot42a_riot42 Posts: 1,624
    TonyAngelo wrote: »
    I put the favs on their own TP port and assign the TP button to the fav number. The only buttons that are on this port are favorite buttons. You only assign buttons to the favorites you want. You want to change the favorites you only have to change the TP file not the code. I don't see any downside.

    You didn't mention the different port in your original post. In my set up you only have to change the numbers in the array once not in every TP file, which I prefer since I find changing numbers in an array quicker than doing it through TPD, Keypadbuilder, etc, and I can use power assign since they are arbitrary channel numbers rather than station numbers, but that's just my preference. Plus since the station numbers aren't hard coded to the channel numbers like with your method, I can have stations past 4000 for moderos, or 255 on some other devices.

    The channel number and station number have nothing to do with each other so I don't like the fact that they are used like that as if they were related somehow. No offense intended but it reminds me of when I saw a colleagues code and he had a constant for the number of outputs on a switch (64). 64 was also the conversion factor used to transform the volume from its native format to a 0-100% format. So in his volume code, rather than create another constant called conversion factor as 64 he just used the one he created as the number of outputs. Needless to say, when we used his file for a switch with only 32 outputs, the volume feedback broke and it took the programmer some time to figure out why. The 20 seconds my colleague saved himself by not creating another constant cost hours during a project with a tight deadline. This is why I don't like making unrelated things seem related in code.
    Paul
  • jjamesjjames Posts: 2,908
    I'll refrain from posting the code yet again, but there's a few users on here (including myself) that use this little piece of code instead of XCH - something in my opinion is pretty darn broken and obsolete.

    http://www.amxforums.com/showthread.php?p=21068#post21068
  • a_riot42a_riot42 Posts: 1,624
    jjames wrote: »
    I'll refrain from posting the code yet again, but there's a few users on here (including myself) that use this little piece of code instead of XCH - something in my opinion is pretty darn broken and obsolete.

    http://www.amxforums.com/showthread.php?p=21068#post21068


    What have you found that is broken? I haven't any problems with it yet. Was it a problem with IR in general or the XCH command in particular? I remember seeing something in the notes a while ago about it being fixed but don't recall what the problem with it was.
    Paul
  • jjamesjjames Posts: 2,908
    Ok, maybe not broken, but don't you remember a couple of years ago when a firmware updated broke XCH? (http://www.amxforums.com/showthread.php?t=1250); using SP avoided that problem. You can use whatever you want, but XCH is obsolete in my opinion, I haven't used it in years, and never intend to. Don't you have more control over the speed of the channels with SP anyway with CTON & CTOF? Or does that effect XCH as well?
  • a_riot42a_riot42 Posts: 1,624
    jjames wrote: »
    Ok, maybe not broken, but don't you remember a couple of years ago when a firmware updated broke XCH? (http://www.amxforums.com/showthread.php?t=1250); using SP avoided that problem. You can use whatever you want, but XCH is obsolete in my opinion, I haven't used it in years, and never intend to. Don't you have more control over the speed of the channels with SP anyway with CTON & CTOF? Or does that effect XCH as well?

    I have always used SP and CTON/CTOF so maybe I never came across this particular issue. I will take your word for the fact that your function works, it just seems to me to be doing alot of very expensive division and modulo for just a cable preset though.
    Paul
  • jjamesjjames Posts: 2,908
    a_riot42 wrote: »
    I have always used SP and CTON/CTOF so maybe I never came across this particular issue. I will take your word for the fact that your function works, it just seems to me to be doing alot of very expensive division and modulo for just a cable preset though.
    Paul
    Toe-may-toe, toe-ma-toe . . . it's all the same I guess. :D
  • a_riot42a_riot42 Posts: 1,624
    jjames wrote: »
    Toe-may-toe, toe-ma-toe . . . it's all the same I guess. :D

    Considering how expensive modulo is I think I would do something like this if I didn't use the XCH command:

    (untested)
    define_function sendFav (dev device, integer fav)
    {
      stack_var integer i, j
      stack_var char station[4]
    
      station = format('%04d', fav)
      
      for (i = 1;i <= 4;i++)
      {
        send_command device, "'SP', atoi(station[i]) + 10"
      }
       send_command device,"'SP', 49"
    }
    
  • Joe HebertJoe Hebert Posts: 2,159
    jjames wrote: »
    Ok, maybe not broken, but don't you remember a couple of years ago when a firmware updated broke XCH? (http://www.amxforums.com/showthread.php?t=1250);
    I remember that thread and if you read it all the way through you?ll see that the firmware didn?t break XCH, it only forced the proper syntax which requires a space between XCH and the channel number. The older firmware let you use XCH with or without a space. The docs have always shown that there needs to be a space between XCH and the channel number.
    jjames wrote:
    Don't you have more control over the speed of the channels with SP anyway with CTON & CTOF? Or does that effect XCH as well?
    Yes, CTON and CTOF affect XCH as well.
    a_riot42 wrote:
    In my set up you only have to change the numbers in the array once not in every TP file, which I prefer since I find changing numbers in an array quicker than doing it through TPD.
    Some choose to write the favorites to disc so that you don?t have to modify the code, recompile, and load a new program every time a channel lineup change occurs.
    a_riot42 wrote:
    I can have stations past 4000 for moderos
    Not if you are using code similar to what you posted using the XCH command. Unless a change has occurred that I?m not aware of XCH only allows 0-999 which is why I also choose to roll my own. If XCH gets updated to allow more than 3 digits I would probably go back to it.
  • a_riot42a_riot42 Posts: 1,624
    Joe Hebert wrote: »
    Some choose to write the favorites to disc so that you don?t have to modify the code, recompile, and load a new program every time a channel lineup change occurs.

    I can see the advantage of doing it this way, although I have never actually changed someone's favs believe it or not. I think the next time I delve into this I will make it user configurable from master files although the amount of work may not be worth it since it isn't something I get a request for very often.
    Joe Hebert wrote: »
    Not if you are using code similar to what you posted using the XCH command. Unless a change has occurred that I?m not aware of XCH only allows 0-999 which is why I also choose to roll my own. If XCH gets updated to allow more than 3 digits I would probably go back to it.


    So far 999 has been good enough. There are already too many channels. I am hoping they switch from quantity to quality sometime soon (yeah right).
  • Joe HebertJoe Hebert Posts: 2,159
    a_riot42 wrote:
    station = format('%04d', fav)
    
    It?s always good to see a fellow format fan.
    a_riot42 wrote:
    So far 999 has been good enough.
    I dumped XCH the first time I did a job that used Dish Network. Dish has a bunch of 4 digit channels going up into the 9,000s.
    a_riot42 wrote:
    There are already too many channels. I am hoping they switch from quantity to quality sometime soon (yeah right).
    When pigs fly. The Boob Tube is such a powerful yet (aside from a few rare exceptions) shamefully underachieving medium when it comes to content. As long as we keep eating it, we?ll continue to get fed garbage. But who I am to talk? One of my favorite channels is GSN. I really get a kick out of watching contestants drop through a trap door on Russian Roulette; I can?t help but smile every time. Goes to show where my intellect level is at. :)

    I think AMX should launch a new TV station called the Netlinx channel, 24/7 non stop programming about programming. I know I?d tune in. :cool:
  • jjamesjjames Posts: 2,908
    Joe Hebert wrote: »
    I remember that thread and if you read it all the way through you?ll see that the firmware didn?t break XCH, it only forced the proper syntax which requires a space between XCH and the channel number. The older firmware let you use XCH with or without a space. The docs have always shown that there needs to be a space between XCH and the channel number.
    That's right. My point was, if you were using XCH, it potentially messed up your system, where as using a function like mine or anything else, you didn't have this problem. Things moved on like normal.
    a_riot42 wrote: »
    Considering how expensive modulo is I think I would do something like this if I didn't use the XCH command...

    Well, considering that I haven't a clue how "expensive" modulo is in terms of slowing down the processor, I would venture to guess that performing a FOR-loop with the FIND_STRING command on top of a defined string variable (which now takes up memory), that just may lose the efficiency battle against modulo.
  • a_riot42a_riot42 Posts: 1,624
    jjames wrote: »
    Well, considering that I haven't a clue how "expensive" modulo is in terms of slowing down the processor, I would venture to guess that performing a FOR-loop with the FIND_STRING command on top of a defined string variable (which now takes up memory), that just may lose the efficiency battle against modulo.

    Modulo tends to be the most expensive mathematical operation you can do since it requires division. I have read that with VXWorks a mod function can actually take up to 30 ms as its emulated in software. Not sure if that's the case with AMX controllers, but I tend to avoid that kind of thing unless absolutely necessary.

    My point with the function above is to trade some memory for cycles, since the memory required is so small, but the cycles needed to perform division is large. Obviously it would need to be analyzed to see which is actually faster, but in general floating point operations on an RTOS are expensive.
    Paul
  • jjamesjjames Posts: 2,908
    a_riot42 wrote: »
    Modulo tends to be the most expensive mathematical operation you can do since it requires division. I have read that with VXWorks a mod function can actually take up to 30 ms as its emulated in software. Not sure if that's the case with AMX controllers, but I tend to avoid that kind of thing unless absolutely necessary.

    My point with the function above is to trade some memory for cycles, since the memory required is so small, but the cycles needed to perform division is large. Obviously it would need to be analyzed to see which is actually faster, but in general floating point operations on an RTOS are expensive.
    Paul
    Definitely interesting. I did not know that. It would be nice to see some analysis done on this, I just don't have the time to do it now. But to be honest, I've been using that code block for quite some time now, and have never noticed a problem.
  • Spire_JeffSpire_Jeff Posts: 1,917
    a_riot42 wrote: »
    Considering how expensive modulo is I think I would do something like this if I didn't use the XCH command:
    jjames wrote: »
    Well, considering that I haven't a clue how "expensive" modulo is in terms of slowing down the processor, I would venture to guess that performing a FOR-loop with the FIND_STRING command on top of a defined string variable (which now takes up memory), that just may lose the efficiency battle against modulo.

    Ok, I had a couple minutes to kill, so I threw a little test together. I used the functions provided (did not test actual functionality) as such:
    define_function fnSendFav (dev device, integer fav)
    {
      stack_var integer i, j
      stack_var char station[4]
    
      station = format('%04d', fav)
      
      for (i = 1;i <= 4;i++)
      {
        send_command device, "'SP', atoi(station[i]) + 10"
      }
    //   send_command device,"'SP', 49"
    }
    DEFINE_FUNCTION fnGET_TV_STATION(DEV dvSOURCE,INTEGER PRESET)
    {
    LOCAL_VAR INTEGER CHAN1[4]
    CHAN1[1] = (PRESET/1000+10)
    CHAN1[2] = (PRESET/100+10)
    CHAN1[3] = ((PRESET%100)/10+10)
    CHAN1[4] = ((PRESET%100)%10+10)
    
    IF(PRESET>=1000)
       SEND_COMMAND dvSOURCE,"'SP',CHAN1[1]"
    
    SEND_COMMAND dvSOURCE,"'SP',CHAN1[2]"
    SEND_COMMAND dvSOURCE,"'SP',CHAN1[3]"
    SEND_COMMAND dvSOURCE,"'SP',CHAN1[4]"
    
    }
    
    

    I then used a button event to run each function 1000 times and get the approximate execution time. I ran each 1000 execution test 10 times in a row for each function. I used the same channel code of 1234 for all tests. The results are as follows:

    First run of 1000 for Modulo: 3110ms
    First run of 1000 for Format: 4700ms

    Second thru tenth run of 1000 for modulo: ~1061ms
    Second thru tenth run of 1000 for Format: ~2676ms

    Do what you will with the results :)

    Jeff
  • a_riot42a_riot42 Posts: 1,624
    Thanks for doing that. Since you have it all setup I am curious if there would be any difference if you unfurl the for loop:
    send_command device, "'SP', atoi(station[1]) + 10"
    send_command device, "'SP', atoi(station[2]) + 10"
    send_command device, "'SP', atoi(station[3]) + 10"
    send_command device, "'SP', atoi(station[4]) + 10"
    
  • a_riot42a_riot42 Posts: 1,624
    I am not sure how you have your timing set up but I was getting almost the same time for each method. Here is a different version you can plug in to try.
    define_function sendFav(dev device, integer fav)
    {
      local_var char station[4]
    
      station = format('%04d', fav)
    	
      send_command device, "'SP', station[1] - 38"
      send_command device, "'SP', station[2] - 38"
      send_command device, "'SP', station[3] - 38"
      send_command device, "'SP', station[4] - 38"	
    }
    
    
  • Spire_JeffSpire_Jeff Posts: 1,917
    a_riot42 wrote: »
    I am not sure how you have your timing set up but I was getting almost the same time for each method.
    Spire_Jeff wrote: »
    I then used a button event to run each function 1000 times and get the approximate execution time. I ran each 1000 execution test 10 times in a row for each function. I used the same channel code of 1234 for all tests. The results are as follows:

    First run of 1000 for Modulo: 3110ms
    First run of 1000 for Format: 4700ms

    Second thru tenth run of 1000 for modulo: ~1061ms
    Second thru tenth run of 1000 for Format: ~2676ms

    Do what you will with the results :)

    Jeff

    First Run of the unfurled for loop: 4703ms
    Second thru tenth run of unfurled: ~2620ms


    Just for fun, I modified the test so that I ran the timed test only once (instead of 1000 times). This produced a very interesting result in which the Modulo version took less than 1ms to run and both of the Format versions took between 2 and 3ms to run. I bumped up the number of tests performed and averaged the results and it seems that the Modulo runs consistently in the 1ms range and the Format versions run in the 2-3ms range.

    The for loop didn't seem to change the results very much.

    Just made it so that the tests ran 10 times and the first tests seemed to be that same amount of time as the 2nd thru 10th (I'm thinking the extra overhead is due to optimization possibly). Anyway, running the tests 10 times seemed to show the corresponding results to running the code once. The increased resolution puts a single run through the Modulo function at ~1.0ms and a single run through the Format function at ~2.6ms.

    Jeff

    P.S.
    These tests are being run on an NI-3100 with no other code really being run. (Ideal conditions if you will :) )

    P.P.S.
    The thing I think I found most interesting was how the processor some how optimized things after the first run through when I had the iterations set to 1000. It was fairly close to double the speed on the strings and almost triple the speed on the Modulo function. I wonder if any AMX employees could shed any light on how the processor might optimize things to make this happen.... then we might be able to exploit this feature in our code.

    P.P.P.S.
    I think I have beaten this horse to death and maybe a bit beyond :) Any other tests I should run?
  • Joe HebertJoe Hebert Posts: 2,159
    Spire_Jeff wrote:
    The increased resolution puts a single run through the Modulo function at ~1.0ms and a single run through the Format function at ~2.6ms.

    Hey Jeff,

    I?m not sure how you performed your tests but I see nothing close to your results on my test NI-700 running DUET with the latest version of firmware. If I?m reading you correctly you?re claiming that FORMAT runs almost 3 times slower than the math version?

    I?ve got two button events and I?m doing a SEND_STRING 0 with a GET_TIMER before and after a FOR loop that calls one of the functions 1000 times. The difference I see is completely negligible, about 1 ms total difference for sending out 1000 presets. So we?re no where near the same ballpark, I?d say not even the same sport. :)

    I also found that using a FOR loop in the preset function does make a difference (at least more of a difference than the two methods), the FOR loop is slower by a couple of ms. But we all know the FOR loop isn?t the fastest beast in the jungle.

    Were you by chance sending the SP commands to a real device? If you were I think that may have tainted your results. I can only guess what happens when you try to stack up 1000s of PULSE commands to a device at one time. I know when I tried it memory took a nose dive and never even recovered 1 byte. I may have stumbled into a memory leak. The max buffer count shot up also (the Con Manager maxed out.) My system seemed to bog down and the SEND_STRING 0s didn?t print out as quickly as the timer indicated.

    Instead of using a real device I sent the SP commands to a virtual since the test has nothing to do with pulsing IR. Memory remained stable along with the buffer count and the SEND_STRING 0s reported in a timely fashion.

    I think the moral of the story is if Jay and others want to divide and use Mod they should feel free to do so, same for those who like FORMAT. And for that matter I see nothing wrong with what Tony posted early on when he related the button channel number to the station channel number. There is no one right way.

    And you thought you obliterated the horse. :)
  • mpullinmpullin Posts: 949
    Joe Hebert wrote: »
    So we?re no where near the same ballpark, I?d say not even the same sport. :)
    I think he's playing that game where a home run is worth 6 runs and everyone throws a party when a batter gets out :)
  • ericmedleyericmedley Posts: 4,177
    mpullin wrote: »
    I think he's playing that game where a home run is worth 6 runs and everyone throws a party when a batter gets out :)

    " An argument can only exist in an environment where two or more people agree to play the game..." ~ unknown...
  • Spire_JeffSpire_Jeff Posts: 1,917
    Joe,

    Here is the code I wrote for the test:
    define_function fnSendFav (dev device, integer fav)
    {
      stack_var integer i, j
      stack_var char station[4]
    
      station = format('&#37;04d', fav)
      
      for (i = 1;i <= 4;i++)
      {
        send_command device, "'SP', atoi(station[i]) + 10"
      }
    //   send_command device,"'SP', 49"
    }
    define_function sendFav(dev device, integer fav)
    {
      local_var char station[4]
    
      station = format('%04d', fav)
    	
      send_command device, "'SP', station[1] - 38"
      send_command device, "'SP', station[2] - 38"
      send_command device, "'SP', station[3] - 38"
      send_command device, "'SP', station[4] - 38"	
    }
    DEFINE_FUNCTION fnGET_TV_STATION(DEV dvSOURCE,INTEGER PRESET)
    {
    LOCAL_VAR INTEGER CHAN1[4]
    CHAN1[1] = (PRESET/1000+10)
    CHAN1[2] = (PRESET/100+10)
    CHAN1[3] = ((PRESET%100)/10+10)
    CHAN1[4] = ((PRESET%100)%10+10)
    
    IF(PRESET>=1000)
       SEND_COMMAND dvSOURCE,"'SP',CHAN1[1]"
    
    SEND_COMMAND dvSOURCE,"'SP',CHAN1[2]"
    SEND_COMMAND dvSOURCE,"'SP',CHAN1[3]"
    SEND_COMMAND dvSOURCE,"'SP',CHAN1[4]"
    
    }
    
    
    
    DEFINE_FUNCTION fnModuloTest() {
    
      INTEGER 	x
      INTEGER 	y
      INTEGER 	tempID
    
      nWORK_IN_PROGRESS = 1	
    	TIMELINE_CREATE(lTL_ID,lTL_Times,5,TIMELINE_RELATIVE,TIMELINE_REPEAT)
    	for(x=1;x<=nLoops;x++){
    		fnGET_TV_STATION(vdvVIRT_IR,1234)
    	}
    	TIMELINE_PAUSE(lTL_ID)
    	lMOD_TIME[nCNTR_MOD] = TIMELINE_GET(lTL_ID)
    	TIMELINE_KILL(lTL_ID)
    	lMOD_TIME[6] = ((lMOD_TIME[6]*lMOD_AVG_CNTR) + lMOD_TIME[nCNTR_MOD])/(lMOD_AVG_CNTR + 1)
    	lMOD_AVG_CNTR++
    
    	IF(nCNTR_MOD == 5)
    		nCNTR_MOD = 1
    	ELSE
    		nCNTR_MOD++
    	nWORK_IN_PROGRESS = 0
    }
    DEFINE_FUNCTION fnCharFavTest() {
    
      INTEGER 	x
      INTEGER 	y
      INTEGER 	tempID
    
      nWORK_IN_PROGRESS = 1	
    	TIMELINE_CREATE(lTL_ID,lTL_Times,5,TIMELINE_RELATIVE,TIMELINE_REPEAT)
    	for(x=1;x<=nLoops;x++){
    		fnSendFav(vdvVIRT_IR,1234)
    	}
    	TIMELINE_PAUSE(lTL_ID)
    	lCHAR_TIME[nCNTR_CHAR] = TIMELINE_GET(lTL_ID)
    	TIMELINE_KILL(lTL_ID)
    	lCHAR_TIME[6] = ((lCHAR_TIME[6]*lCHAR_AVG_CNTR) + lCHAR_TIME[nCNTR_CHAR])/(lCHAR_AVG_CNTR + 1)
    	lCHAR_AVG_CNTR++
    
    	IF(nCNTR_CHAR == 5)
    		nCNTR_CHAR = 1
    	ELSE
    		nCNTR_CHAR++
    	nWORK_IN_PROGRESS = 0
    }
    DEFINE_FUNCTION fnCharFavTest2() {
    
      INTEGER 	x
      INTEGER 	y
      INTEGER 	tempID
    
      nWORK_IN_PROGRESS = 1	
    	TIMELINE_CREATE(lTL_ID,lTL_Times,5,TIMELINE_RELATIVE,TIMELINE_REPEAT)
    	for(x=1;x<=nLoops;x++){
    		sendFav(vdvVIRT_IR,1234)
    	}
    	TIMELINE_PAUSE(lTL_ID)
    	lCHAR_TIME[nCNTR_CHAR] = TIMELINE_GET(lTL_ID)
    	TIMELINE_KILL(lTL_ID)
    	lCHAR_TIME[6] = ((lCHAR_TIME[6]*lCHAR_AVG_CNTR) + lCHAR_TIME[nCNTR_CHAR])/(lCHAR_AVG_CNTR + 1)
    	lCHAR_AVG_CNTR++
    
    	IF(nCNTR_CHAR == 5)
    		nCNTR_CHAR = 1
    	ELSE
    		nCNTR_CHAR++
    	nWORK_IN_PROGRESS = 0
    }
    
    
    .
    .
    .
    
    BUTTON_EVENT[dvTP,8] {  //fnGET_TV_STATION
    
    	PUSH: {
    		STACK_VAR INTEGER x;
    		FOR(x=1;x<=nNumTests;x++)
    		{
    			fnModuloTest();
    		}
      }
    }
    BUTTON_EVENT[dvTP,9] {  //fnSendFav
    
    	PUSH: {
    		STACK_VAR INTEGER x;
    		FOR(x=1;x<=nNumTests;x++)
    		{
    			fnCharFavTest();
    		}
      }
    }
    BUTTON_EVENT[dvTP,10] {  //fnSendFav
    
    	PUSH: {
    		STACK_VAR INTEGER x;
    		FOR(x=1;x<=nNumTests;x++)
    		{
    			fnCharFavTest();
    		}
      }
    }
    
    

    I modified nLoops and nNumTests via the debugger. Everything was being sent to a virtual device. There is a good chance that I have some flawed logic in my benchmark test, let me know when you find my obvious mistake.

    Jeff

    P.S.
    There is more code, but these are the important parts.
  • a_riot42a_riot42 Posts: 1,624
    Joe Hebert wrote: »
    I know when I tried it memory took a nose dive and never even recovered 1 byte. I may have stumbled into a memory leak. The max buffer count shot up also (the Con Manager maxed out.) My system seemed to bog down and the SEND_STRING 0s didn?t print out as quickly as the timer indicated.

    Ugh, that's a bad leak. If the remote gets inbetween cushions on the couch so that a button is held indefinitely, I wonder if there would be an issue with memory leakage. I would have thought that as soon as the IR command is finished pulsing then the memory would be returned to the system.
    Paul
  • jjamesjjames Posts: 2,908
    Joe Hebert wrote: »
    I think the moral of the story is if Jay and others want to divide and use Mod they should feel free to do so, same for those who like FORMAT. And for that matter I see nothing wrong with what Tony posted early on when he related the button channel number to the station channel number. There is no one right way.
    Absolutely. I've said plenty of times before, it doesn't matter HOW you do it, as long as the end result is the desired result for the client.

    Besides, was there even a horse to begin with? What's a couple of milliseconds when tuning to a channel? Don't get me wrong, a very fun exercise, and I appreciate all the work Jeff has put in, I just wonder . . . does it make a difference on the end result? :D
  • Spire_JeffSpire_Jeff Posts: 1,917
    jjames wrote: »
    What's a couple of milliseconds when tuning to a channel? Don't get me wrong, a very fun exercise, and I appreciate all the work Jeff has put in, I just wonder . . . does it make a difference on the end result? :D

    Thank you for the appreciation, for starters. As for the couple of milliseconds....you add up ms and you get M$.... need I say more?

    I do think that it is a bad habit to ignore the impact of code on the processor. As some have surely found out, coding that works when there is a single processor with only a handful of devices and a single touch panel, is not guaranteed to work when more devices are added and the number of touch panels multiplies.

    Next thing you know, you're coding in a 3d simulator to display the names of the programmer(s), but only if they push all of the correct buttons in the correct order..... hmm, sounds like an interesting idea tho... if the customer turns on the correct lighting scene, followed by the hot tub, then the fireplace, then the Barry White play list, the touch panels displays a big thumbs up! ... or maybe a pair of dice roll across the screen and then land with a total of 7! :)

    Jeff

    P.S.
    I may have inhaled a bit of carbon monoxide today while working next to a generator.... does it show? :)
  • jjamesjjames Posts: 2,908
    Spire_Jeff wrote: »
    I do think that it is a bad habit to ignore the impact of code on the processor. As some have surely found out, coding that works when there is a single processor with only a handful of devices and a single touch panel, is not guaranteed to work when more devices are added and the number of touch panels multiplies.
    Yup - I agree with that too. As much as I strive for that "one size fits all" code, I know sometimes you have to tailor it at times. Typically, if it works great on a huge system, it'll work great on the smaller system.

    And about the fumes . . . nope, couldn't tell. Not one bit. Seriously. I thought you just ate some fish from Lake St. Clair. :D
Sign In or Register to comment.