|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Sat Apr 30, 2022 6:04 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Sun May 01, 2022 1:17 pm Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Mon May 02, 2022 6:16 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Mon May 02, 2022 7:27 am Post subject: |
|
|
Ooops. They were inadvertently removed in d142de52de850fe1b7c60079a87a521f1ac7b34. Using too strong detergent when cleaning up...
A fixed version has been checked in. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Mon May 02, 2022 9:29 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Tue May 03, 2022 5:29 am Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Tue May 03, 2022 12:18 pm Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Wed May 04, 2022 8:03 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Wed May 04, 2022 2:32 pm Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Thu May 05, 2022 5:38 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Thu May 05, 2022 1:53 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Fri May 06, 2022 9:00 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Thu May 12, 2022 3:16 pm Post subject: |
|
|
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 |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4530 Location: Cambridge, UK |
Posted: Tue May 24, 2022 6:13 am Post subject: |
|
|
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 |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Tue May 24, 2022 4:32 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
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
|