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

IrpTransmogrifier: new program/library for IRP protocols
Goto page Previous  1, 2, 3 ... 11, 12, 13, 14  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

                    
PostPosted: Sat Apr 30, 2022 6:04 am    Post subject: Reply with quote

Are you planning a new release of IrpTransmogrifier in the near future? I hope shortly to make a new official release of RMIR and will wait for a new IrpTransmogrifier if it too will be ready shortly, otherwise I will stick to v1.2.10.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Sun May 01, 2022 1:17 pm    Post subject: Reply with quote

I plan to release version 1.2.11 as a stable version within the next few weeks. There will also be a corresponding Girr release (2.2.11).

There will not be any dramatic changes since 1.2.10, mainly small bug fixes and extensions. The current snapshot is quite close to the final version; so feel free to try the current snapshot.

More substantial changes in the sense of #111 will not be included in this release.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

                    
PostPosted: Mon May 02, 2022 6:16 am    Post subject: Reply with quote

What has happened to NamedProtocol.getAbsoluteTolerance and NamedProtocol.getRelativeTolerance? I use them in RMIR but there no longer seems to be a way of getting those values.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon May 02, 2022 7:27 am    Post subject: Reply with quote

Ooops. Embarassed They were inadvertently removed in d142de52de850fe1b7c60079a87a521f1ac7b34. Using too strong detergent when cleaning up...

A fixed version has been checked in.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

                    
PostPosted: Mon May 02, 2022 9:29 am    Post subject: Reply with quote

Thanks for the speedy fix. RMIR now compiles and runs with the latest snapshots of both IrpTransmogrifier (c5840d8) and Girr (d0af52c). No time for proper testing yet, but I will report if I find any problems.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Tue May 03, 2022 5:29 am    Post subject: Reply with quote

I have just spotted a typo in rmProtocols.xml that has got propagated into your merged IrpProtocols.xml. In version c5840d8 it is at line 1288. The line ends in two > signs but there should only be one. The erroneous line is

Code:
<rm:translator target="power1">power1|Off|On</rm:translator>>

I think it gets ignored in processing, or I would have found it before, but it would be better if it were corrected.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Tue May 03, 2022 12:18 pm    Post subject: Reply with quote

In IrpProtocols.xml, in fixing the IRP repeat in NEC1-Yamaha, you have inadvertently also added in a spurious extra documentation entry. Here is an extract of what is currently there:

Code:
    <irp:protocol name="NEC1-Yamaha">
        <irp:irp>
            <![CDATA[{38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,E0:1,~F:6:1,E7:1,1,^108m,(16,-4,1,^108m)*) {E0=(~Y:1:1)^(F:1),E7=(~Y:1)^(F:1:7)}[D:0..255,S:0..255=255-D,F:0..255,Y:1..3]]]>
        </irp:irp>
        <irp:documentation xml:space="preserve">Variant of the <a href="#NEC1">NEC1</a> protocol with the checksum in byte 4 different
(complement all of F except the MSB).
        </irp:documentation>
        <irp:documentation xml:space="preserve">A variant of the <a href="#NEC1">NEC1</a> protocol which differs in the relationship between bytes 3 and 4.
            Instead of byte 4 being the complement of byte 3, the relationship is determined by the value of the Y parameter, as follows:
            <ul>
                <li>Y=1: Only bits 0-6 are complemented.</li>
                <li>Y=2: Only bits 1-7 are complemented.</li>
                <li>Y=3: Only bits 1-6 are complemented.</li>
            </ul>
        </irp:documentation>

The second entry, with the different Y values documented, is the correct one.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Wed May 04, 2022 8:03 am    Post subject: Reply with quote

Thanks for making the fixes to IrpProtocols.xml. If you are interested, I have now uploaded RMIR v2.14.13 to the SVN which incorporates your latest snapshots, d5e8d1c for IrpTransmogrifier, d0af52c for Girr. Remember, if you try to run this build, that you need to do mvn validate first, to install the snapshots from the libs subfolder. I do not intend to issue this as a development build unless something occurs that necessitates a new build before you are ready with your new release versions.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Wed May 04, 2022 2:32 pm    Post subject: Reply with quote

The "typos" in IrpProtocols.xml has been checked in (thank you!), but you seem to have noticed that already.

I got your new SVN version, and, without making extensive tests, did not find any peculiarities.

However, one thing disturbed my consciousness: The new getRelativeTolerance (and the three other get-ters) return null if the variable is not assigned in the current protocol, the old one returned the default value (IrCoreUtils.DEFAULT_RELATIVE_TOLERANCE). I have added functions getRelativeToreranceWithDefault that returns the default, if not assigned. (Correspondingly, the get*() return Double, the get*WithDefault return double.) Use any you want.

Checked in as 5d7fc3b19ec2c5e7ff2ac015a80939eb465e119f.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

                    
PostPosted: Thu May 05, 2022 5:38 am    Post subject: Reply with quote

Thanks for pointing out this change. I have looked into my code and I use the returned values only once, in a call to the constructor Analyzer( irSignal, absTol, relTol ) where absTol and relTol are the returned Double values. On looking into your code, if I read it correctly then in due course these Double values are converted to double values by calls to IrCoreUtils.getDoubleWithSubstitute(Double userValue, double fallback), which converts nulls to the appropriate default value. If I am right then this means that all is well and that I do not need to change anything. Can you confirm that this is correct, that I haven't missed some other use in the constructor where nulls are not converted to default values?
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu May 05, 2022 1:53 pm    Post subject: Reply with quote

First, I think it would be more logical to use get*WithDefault() for the parameters of a protocol, since you want the actual, current parameter value, and do not care (here) if it is a special value, or happens to be the default value.

mathdon wrote:
if I read it correctly then in due course these Double values are converted to double values by calls to IrCoreUtils.getDoubleWithSubstitute(Double userValue, double fallback), which converts nulls to the appropriate default value. If I am right then this means that all is well and that I do not need to change anything.

Well, yes, while the current defaults in the protocols are the same as the defaults in the Analyzer, but this is not a guaranteed and documented property, and may not be true in the future.

You pick the parameters of the first decoded protocol, and feed it to an Analyzer constructor. I do not consider this a good idea. The analyzer should do its job independent of the decoder. The tolerances of the Analyzer are used to determine how the measured durations are grouped, which is pretty different from the usage in the decoder. Suggestion: just use the Analyzer(IrSignal) constructor. Then you do not need NamedProtocol.get*Tolerance() either Wink
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

                    
PostPosted: Fri May 06, 2022 9:00 am    Post subject: Reply with quote

Barf wrote:
The analyzer should do its job independent of the decoder.

In an ideal world the analyzer should just take an IrSignal and find the best analysis without further help, but the world is not ideal so it takes tolerances as parameters to provide context. The analysis display in RMIR does not pretend to be ignorant of the decode. Its aim is to present the signal data in an IRP form that can be compared with one derived from the IRP used by the decoder, which is also displayed. There are two possible choices of tolerance values for the analyzer, the default values and those used by the decoder, if different. For this use it seems to me that the best choice is those used by the decoder. Of course, if there is no decode then only the analysis is displayed and that will have used the defaults.

Barf wrote:
I think it would be more logical to use get*WithDefault() for the parameters of a protocol ... while the current defaults in the protocols are the same as the defaults in the Analyzer, ... this is not a guaranteed and documented property, and may not be true in the future.

I have done as you suggest, now in the SVN, though any change you make in the future can be addressed at that time. I'm not a fan of future-proofing, as very often the future you proof against isn't actually what happens.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Thu May 12, 2022 3:16 pm    Post subject: Reply with quote

Release candidate 1 of IrpTransmogrifier 1.2.11 and Girr 2.2.11 are available in the usual locations. Only main difference from recent version is that protocol F12 has prefer-over F12x. (Otherwise all F12 decodes also decode as F12x).

Please let know if there are any issues within, say, a week.

Release notes
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


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

                    
PostPosted: Tue May 24, 2022 6:13 am    Post subject: Reply with quote

Barf wrote:
Please let know if there are any issues within, say, a week.

In case you missed my PM, I have found no issues with your RC1 in my testing, so as far as I am concerned it is ready for issue as final.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue May 24, 2022 4:32 pm    Post subject: Reply with quote

IrpTransmogrifier 1.2.11 and Girr 2.2.11 have been released.

Release notes: (The notation #n refers to issues number n at https://github.com/bengtmartensson/IrpTransmogrifier/issues .)
Code:
This version consists mainly of a few extensions, bugfixes and cleanups.

* If DecoderParameters.allDecodes is true, indicate which decode is preferred with new API call.
* Bugfix/cleanup on decoder parameter and --override handling. #214.
* Some cleanup of XML code generation.
* Decoded protocol parameters (in toString()) now ordered as in the IRP ParameterSpecs. #207.
* Analyze now optionally generates ParameterSpecs in the IRP. Resolves #202.
* New protocols: Eufy, F12x, Keeprite. ((From RMIR).
* Bugfix in  IrpDatabase.toElement(Document ...). #219.
* Add intro, repeat, ending to --classify output. #218.
* Remove cName (@c-name in XML) completely. #217.
* Rename min-leadout to minimum-leading (pull request #212 from seanyoung).
* Bugfix for IrCoreUtils.parseLong(String, boolean, int). #211.
* New function IrpDatabase.setDocumentation.


Graham, sorry for not answering faster. I got and read your PM. Embarassed
Back to top
View user's profile Send private message Send e-mail Visit poster's website
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 ... 11, 12, 13, 14  Next
Page 12 of 14

 
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