JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Volume punch-through without mute punch-through
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Thu Mar 16, 2023 1:24 pm    Post subject: Reply with quote

mathdon wrote:
It's a simple text box that one can type into, no context menu. Just use Ctrl/V to paste.

Done that, and created the artificial learn. It tests successfully. Very Happy

However, comparing it with the genuine learn, RMIR does not display identically:

- In the genuine learn, the MUTE button in "Functions" displays as "_missing1".
- In the artificial learn, it displays as "Mute toggle" (which is how I had named it originally).

- In the genuine learn, the MUTE button in "Buttons" displays as "Learn: Mute" (in bold).
- In the artificial learn, it displays as "Mute toggle".

- On the "Learned Signals" tab, the "IRP from analysis" and "IRP from decode" are virtually identical. There are slight difference in the frequencies, but that is probably not significant.

Do any of these differences matter, and could they cause problems subsequently?

-- from CyberSimian in the UK
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Mar 16, 2023 2:11 pm    Post subject: Reply with quote

They do not matter, they are display issues only and will not cause any problems. The artificial learn has all the info it needs to display button and function names, as you have entered it. For the real learn RMIR has to create names. As for the IRP, the learn process cannot time the signal pulses exactly so the frequency and timing values are subject to slight errors which usually are not significant. The artificial learn will be true to the protocol specification.

You can use either, but my preference would be for the artificial learn. I would never now do a real learn except as a test. For a signal to actually use, I would always create an artificial one in this way from the IRP.
_________________
Graham
Back to top
View user's profile Send private message
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Fri Mar 17, 2023 3:51 am    Post subject: Reply with quote

mathdon wrote:
They do not matter, they are display issues only and will not cause any problems.

That is a relief! When I first created the artificial learn and saw these differences, I thought that there was something wrong and that the definition would not work. But then I thought that I should probably test it, and it worked fine. Very Happy

mathdon wrote:
You can use either, but my preference would be for the artificial learn. I would never now do a real learn except as a test. For a signal to actually use, I would always create an artificial one in this way from the IRP.

Yes, I agree with this, and I am pleased to say that I have learned something new about RMIR and how to use it. Smile

Thank you very much for helping me with this. It is much appreciated, and I will now be able to go forward and create the complete definition for the XSight Lite to control all of my devices. And thanks to Rob too for his suggestions and offers of help. Very Happy

-- from CyberSimian in the UK
Back to top
View user's profile Send private message
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Mon Mar 20, 2023 4:08 am    Post subject: Reply with quote

mathdon wrote:
This method should work for almost all protocols, so unless your devices use very unusual protocols, all should now be well.

Oh dear! It looks like my Cambridge Audio CXN streamer DAC does use an awkward protocol.

I created an upgrade for the CXN using the "RC-5/5x Combo" protocol; see this file in the Files Section: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26691. If I follow your procedure to obtain the GIRR file, the entry for the MUTE button looks like this:

Code:
<ccf T="0">0000 0073 0000 000B 0020 ... </ccf>
<ccf T="1">0000 0073 0000 000C 0020 ... </ccf>

from which I conclude that the protocol uses toggle codes (hence two definitions for each function). Is that what this notation means?

I noticed that on the "Learned Signal Details" panel, the "Signal Data" box has selections for odd and even keypresses. So I selected "Odd" and pasted the value for <ccf T="1"> and clicked "Apply". Then I selected "Even" and pasted the value for <ccf T="0"> and clicked "Apply". But the second paste seems to have overwritten the first paste, so only one value has been stored.

Have I not used the correct procedure for pasting a learned toggle code, or can artificial learned toggle codes not be created in this way? Thank you.

-- from CyberSimian in the UK
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Mar 20, 2023 5:01 am    Post subject: Reply with quote

I'm afraid there is no such thing as a learned toggling signal. A real learn is a learn of only one signal. The learn process has no way of knowing that the next signal would be different. Since a real learn cannot know this, the way it is encoded in the remote has no way of specifying a toggle, so artificial learns also cannot do it. That is why there are radio buttons in the new learned dialog for Odd and Even keypresses, to specify which toggle state you want.
_________________
Graham
Back to top
View user's profile Send private message
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Mon Mar 20, 2023 5:47 am    Post subject: Reply with quote

mathdon wrote:
The learn process has no way of knowing that the next signal would be different. Since a real learn cannot know this, the way it is encoded in the remote has no way of specifying a toggle, so artificial learns also cannot do it.

I tested the artificial learn for the MUTE button for the Cambridge DAC, but as expected it did not work properly. The first press of the MUTE button muted the sound, but subsequent presses did nothing (so the sound could not be unmuted using the Xsight Lite).

Is there any way that I can get this work properly, or am I out of luck?

-- from CyberSimian in the UK
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Mon Mar 20, 2023 11:51 am    Post subject: Reply with quote

Can you post a .rmir file of your setup, so I can see exactly what you are dealing with, please?
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Mon Mar 20, 2023 2:33 pm    Post subject: Reply with quote

CyberSimian, you need to understand how signals with a toggle bit work. Devices that use a toggle bit do so to help them differentiate between a user pressing the button twice and a button held down. On the OEM remote, every time you press a new button, a toggle bit changes, so if you keep pressing the same button, it will send a different signal each time, first with the toggle ON, then OFF, then ON, etc.

A JP1 upgrade replicates this, but a learned signal cannot. A learned signal can only have the toggle either ON or OFF, so a learned signal with a toggle will only work once. To keep using the learned signal, you will need to press another button in between.

If you can think of a button that would do no harm if it were to be pressed after every MUTE button, we could construct some Pronto hex which sends both together, then the learned MUTE might do what you expect.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Tue Mar 21, 2023 8:12 am    Post subject: Reply with quote

mathdon wrote:
Can you post a .rmir file of your setup, so I can see exactly what you are dealing with, please?

I have added the RMIR file to the Diagnosis section:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26692

It contains six devices (amp, cd, dac, htpc, radio, tv). The amp and cd devices are still "works in progress", but the other devices are more or less as I want them.

-- from CyberSimian in the UK
Back to top
View user's profile Send private message
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Tue Mar 21, 2023 8:38 am    Post subject: Reply with quote

The Robman wrote:
Devices that use a toggle bit do so to help them differentiate between a user pressing the button twice and a button held
down.

Yes, I encountered the toggle-flag problem when I used a Microsoft MCE remote control with a Sony amplifier, and then with my current Teac amplifier. All three of these devices use a toggling protocol, and as a result interfere with each other when a universal remote is used. The characteristic symptom is that the MCE button is ignored if pressed after a single press of an amplifier button. But the second press of the MCE button always works (but this is, nevertheless, very irritating).

The Robman wrote:
A learned signal can only have the toggle either ON or OFF, so a learned signal with a toggle will only work once. To keep using the learned signal, you will need to press another button in between.

Yes, I have just tried that and that works. So the first press of MUTE works, but subsequent presses of MUTE are ignored (if no other button intervenes). However, pressing some other button on the DAC remote then allows the MUTE button to work (i.e. unmute the DAC) when pressed subsequently.

The Robman wrote:
If you can think of a button that would do no harm if it were to be pressed after every MUTE button, we could construct some Pronto hex which sends both together, then the learned MUTE might do what you expect.

I have just been reviewing the set of DAC buttons, and there is one that could be used. There are several codes that control the LCD display (bright, dim, off, and toggle). The DAC powers off the display after a timeout, but redisplays it whenever a button is pressed. So creating a composite of MUTE followed by LCD_BRIGHT would probably cure the toggle-flag problem without generating a visible side effect.

-- from CyberSimian in the UK

Edit: changed "with" to "without".
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Mar 21, 2023 11:44 am    Post subject: Reply with quote

CyberSimian wrote:
I have just been reviewing the set of DAC buttons, and there is one that could be used. There are several codes that control the LCD display (bright, dim, off, and toggle). The DAC powers off the display after a timeout, but redisplays it whenever a button is pressed. So creating a composite of MUTE followed by LCD_BRIGHT would probably cure the toggle-flag problem without generating a visible side effect.

Try replacing the code for the DAC MUTE button with this:

0000 0073 0015 0000 0020 0020 0040 0040 0040 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0020 0CA8 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0040 0040 0020 0020 0040 0040 0CC8

I've made this non-repeating because I don't think a MUTE button needs to repeat when held but if you find that it does, I could re-do it.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Tue Mar 21, 2023 1:22 pm    Post subject: Reply with quote

The Robman wrote:
Try replacing the code for the DAC MUTE button with this

Thank you for the modified data for the DAC mute button. I tested it, but unfortunately it does not change the mute status -- the sound continued unabated. Sad

However, I did notice that if the display was set to dim, pressing the MUTE button caused it to brighten. This is different from the original behaviour, whereby pressing MUTE displays "X" for one second before reverting to the previous display, but the brightness does not change -- if it was dim originally, it remains dim throughout this sequence. So the modified definition is having some effect. Smile

-- from CyberSimian in the UK
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Mar 21, 2023 6:43 pm    Post subject: Reply with quote

Try this version instead then:

0000 0073 000A 000B 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0040 0040 0020 0020 0040 0040 0CC8 0020 0020 0040 0040 0040 0020 0020 0020 0020 0020 0020 0020 0020 0020 0020 0040 0020 0020 0040 0040 0020 0CA8
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
CyberSimian



Joined: 24 Oct 2013
Posts: 74
Location: Southampton, UK

                    
PostPosted: Wed Mar 22, 2023 3:38 am    Post subject: Reply with quote

The Robman wrote:
Try this version instead then.

Brilliant! Works great! Very Happy

I usually have the DAC LCD set to bright, which is why I suggested using the LCD_BRIGHT function. But I also tested with the display set to dim, and surprisingly the display remained dim when the MUTE button was pressed. I had expected that it might change to bright, but the DAC must be doing something else after it has processed the MUTE signal. However, this is actually a better outcome (for anyone who wants to use dim on this DAC!).

Many thanks.

-- from CyberSimian in the UK
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Mar 22, 2023 6:00 am    Post subject: Reply with quote

Thanks, Rob, for this very interesting work-around. It would never have occurred to me to use the fact that for a toggling protocol the toggle alternates on successive signals, regardless of what signal is being sent. So by sending a another signal after each Mute, the device always expects the Mute to have the same toggle value, which the learned Mute supplies. My thoughts had only been to try to find a way to get successive Mutes to have alternate toggle values and I could see no way of achieving that.
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control