Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Any new Yamaha AVR models to do?
So, a while back some work was done on a 'universal' Yamaha driver. At first it appeared we could actually really do a universal driver. They had a great concept with full 'introspection' where the driver could query everything about the device and automatically set itself up. It would have meant one driver could work for a large number of models.

Of course they were too stupid to actually do that, and shortly thereafter completely broke it. So, we did something like sort of like the recently introduced Denon 'Universal' driver in that there's an overall base class that does almost all the work and a small per-model class that allows for some per-model smarts to provide needed info.

So far, that has only been used on one model, that I know of, the RX-A2050. But it could be used to support various other models. It will only work with those that support Yamaha's YNC protocol, but I think that's pretty much all of them these days, though older ones didn't. We have some existing drivers for those older models that we could otherwise convert to this 'universal' scheme and get rid of some redundancy, but that cant' be done. Still anything from the last couple years forward should be YNC compatible presumably. 

So if anyone has any Yamaha YNC compatible models they want supported, let me know and let's work on that and get some more up to date models supported. It should require very minimal work, as long as they haven't gone even further off the deep end and broken compatibility yet again. But, even then, with this per-model scheme, most likely we can get around the issues.
Dean Roddey
Explorans limites defectum
We currently have a RX-V1900 (as assoc. driver) installed.

Not sure if its using the YNC protocol or not. Willing to help with testing, but it may be difficult as its behind a corporate firewall. Need to talk offline to see what can be done re access.
Mykel Koblenz
Illawarra Smart Home
I'm think that's one of the pre-YNC models, because that driver has been around for a long time. I looked at the current driver code for that guy, and it's the old style protocol.
Dean Roddey
Explorans limites defectum
I have an RX-A3000. I wish I could select Sirius channels
I don't think that this would help on that front. The generic functionality of this driver doesn't understand anything that specific.
Dean Roddey
Explorans limites defectum
That's the problem with the scheme in general. It takes the lowest common denominator approach so our high end equipment performs no better than the bottom of the barrel models. Most disappointing.
It's either have extremely extensive support for a small number of models, or have broad support for core stuff that everyone is going to need. Over time of course we can expand on this stuff, but for now we need to get more models supported, and make it easy for others to add model support as well.

We could of course add a 'passthrough' field to let you send raw commands in some cases. I'd have to look at it though since the Yamaha uses an XML format, so I'd have to see if there's some reasonable way to handle that. It's potentially harder to do than something that uses a simple formatted string format.
Dean Roddey
Explorans limites defectum
This is my biggest disappointment in CQC by far. Think about it; do people interested in HA typically buy the most feature-less product in a manufacturers portfolio? I'd bet the answer is no. Yet with these drivers they behave like the low end equipment. I'm sorry if this seems harsh but it's been a source of frustration with the V2 scheme since the beginning. I would encourage you to consider another way to accomplish your goals of versatility with our goals of being able to fully utilize our [expensive] equipment.
This isn't really a V2 thing. V2 compatible drivers can have non-V2 functionality. Certainly, we cannot expect to support lots of detailed functionality and still get the benefits that the V2 system provides. If you want to go beyond that, you have to do your own customization work and that really cant' be gotten around. But we can of course have non-V2 stuff in the driver if you want to use it in your own custom logic and interfaces.

The issue here is to be able to make support of a new model something less than an epic endeavor, which it has traditionally been, and that has really hurt us. People come and look at what we support and don't see lots of recent models. We need to make supporting those new models vastly easier, not just for me but to encourage others to do it. So we need to limit how much stuff is supported, or no one will do it. It'll end up being too complicated.

We can add some extra stuff to it, but everyone will want something different. So an obvious way to deal with it is to provide a pass-through field so you can send commands directly where you need to access something beyond what we are generically supporting.
Dean Roddey
Explorans limites defectum
It looks like handling simple commands via a pass-through should be doable. That would make it easily enough to select a preset for a given streaming source. You'd have to provide something like a path to the thing to change:


and the value to write, which would be a preset number. That would be enough to let me build the XML required to send the command.
Dean Roddey
Explorans limites defectum

Possibly Related Threads...
Thread Author Replies Views Last Post
  Yamaha customer Service batwater 2 1,647 07-11-2010, 05:33 AM
Last Post: batwater
  Yamaha receiver in the basement? beelzerob 7 3,463 01-16-2008, 05:36 PM
Last Post: dkemme
  Yamaha RS232 protocol docs NarcolepticFoo 1 2,739 01-03-2007, 02:57 PM
Last Post: Helheim
  Audiophile 2496 to Yamaha RX-V1600 mshid 0 1,292 09-20-2006, 07:28 PM
Last Post: mshid
  Yamaha iPod Integration jkmonroe 12 3,886 09-17-2006, 07:53 PM
Last Post: Dean Roddey
  Yamaha HTR zaccari 5 2,292 09-15-2006, 01:54 PM
Last Post: jkmonroe

Forum Jump:

Users browsing this thread: 1 Guest(s)