Before you start blaming developers, think about how products are really created! The product concepts and specifications are made by the design and business teams. Developers just implement what is wanted ;)

BR One was intended as NL device remote and Beo4 support is only a addon to that, so maybe its time to let go the old...

Kulles wrote:

Before you start blaming developers, think about how products are really created! The product concepts and specifications are made by the design and business teams. Developers just implement what is wanted ;)

BR One was intended as NL device remote and Beo4 support is only a addon to that, so maybe its time to let go the old...

Kulles wrote:

Before you start blaming developers, think about how products are really created! The product concepts and specifications are made by the design and business teams. Developers just implement what is wanted ;)

I do not agree with you on that - most certainly not!

MM

YannChris wrote:

Sorry Carolpa,

I use this function on my BS3 based BV9 with a Tvix on the VMEM input.

The audio source is a BC2 with a Playmaker on the AUX input (Playmaker is linked to a NAS and controlled through an iPad).

The command  sequence is this one:

- VMEM + A.AUX

Kind regards,

Yann.

Hi Yann

Ever tried to start a Beomaster as a sound source on the BV9 while watching TV?

That is the real AV function MM intends to discuss. That was a nice feature on f.e. an AV9000 - watching a soccer game while listen to music.

regards

Millemissen wrote:

Kulles wrote:

Before you start blaming developers, think about how products are really created! The product concepts and specifications are made by the design and business teams. Developers just implement what is wanted ;)

I do not agree with you on that - most certainly not!

MM

MM - there is actually a lot of truth in what Kulles has said (at least that is the way it should work in theory).

To give a parallel example, if you instruct an architect to design a house for you, and then builders are employed to build that house based on the design the architect has produced, it would not be fair to blame the builders if there was no ensuite bathroom for bedroom 3 if one was not shown on the plan / specification. It would either be the fault of the architect (if you had clearly communicated that requirement to him), or your fault if you had not done so, and had not taken the time to check the specification he produced met your requirements - before the house was built...

Software developers work to a specification too - to leave them to decide themselves on what features might be required would be commercial suicide as the project would either never be completed, or would not meet its requirements.

Unfortunately what often happens (and I speak from experience) is that these sorts of omissions are picked up at some point during the implementation process, but long after the design has been finalised and decisions have been made regarding how the software will be implemented.

This means either leaving out the 'forgotten' features altogether, returning to the design stage (and scrapping most or all of the code that has already been written), or somehow trying to shoehorn these features into the current design schema despite the fact they don't really fit. Obviously both of the latter options will have an impact on timescales, and the last option in particular risks breaking other aspects of the design and introducing bugs that would not otherwise have been present.

Kind Regards,

Martin.

I wasn't talking about constructing a house or how X-company develops their products!

I was talking about what is going on in Struer - how B&O works - and that is not like, what Kulles described.

MM

So you have a inner knowledge how B&O is developing its products and software?

B&O is doing it the same way as all the big companies do. After all its 90 years old company, not some start up that can build up their product with two developers in their garage ;)

Carolpa,

This is exactly what I described with other sources (I'm not fan of soccer, but like to travel with my pictures).

BL5 are connected to BV9 and BC2 has no speakers plugged in.

But there was a typo in my post.

The sequence is VMEM + AV/A.AUX.

It could be TV + AV/CD.

Or any other combination of sources.

And it is available on BS3 systems.

Kind regards,

Yann.

Millemissen wrote:

I wasn't talking about constructing a house or how X-company develops their products!

I was talking about what is going on in Struer - how B&O works - and that is not like, what Kulles described.

MM

Neither Kulles nor I were talking about the product development process as a whole, but instead about how programmers work and what their responsibilities are.

Since you didn't like my construction analogy 😕 - consider instead the aluminium factory - their brief would not be simply "create an enclosure for product x" - they would have a design and specification to work to and would then be responsible for deciding on how this can be manufactured and what tooling will be required etc. In reality it's never going to be as top down as this because the designers will require feedback from the aluminium specialists at an early stage as to what is possible with a given material and this will feedback into the design - often with changes being required to make the design possible to physically manufacture (or to do so within a given cost constraint).

Software development is no different. The point I believe Kulles was making was that you can't blame the people who write the code for missing features if they weren't part of the original design / specification, and the point I was making is that once a project has progressed beyond the design stage it can be very difficult / expensive / time consuming to add that feature later as it will often not fit neatly into the existing software design so either requires a new design, and a major rewrite of existing code to implement it, or an attempt is made to simply force it into the existing design (with the risk of breaking other parts in the process).

To respond more directly to your original points:

Millemissen wrote:

This is a question about the factual background and would require, that someone knows a thing or two about this. 

As someone with a background in software development I've responded with my best guess based on the known fact (namely that the feature has not been implemented) and based on how the software development process usually works. Likely the only more accurate response you will receive is if anyone within the team at B&O decides to respond in person. I'm sorry if you do not like my conclusions but they are reasonable given what is known. You have mentioned that this is not how the software development process works at Struer and if you would care to elaborate on this further I will re-examine my conclusions accordingly.

Millemissen wrote:

As far as I am concerned, it has to do with the ML network as a Master/Slave(Link) setup and the NL as a network of equal sources, that (at least theoretically) can be accessed from everywhere on the network.

The master / slave versus peer to peer topologies should not have had any direct impact on the technical feasibility of this feature being implemented (if it had been specified at the design stage).

Millemissen wrote:

So - who is able to explain this?

Or - in other words - who could explain, why there is no A/V function in a NL setup!

Since there is no obvious technical constraint which would make this feature impossible to implement, my best guess would be whoever decided not to include it in the original design / specification. Maybe this was a conscious decision not to do so (perhaps because it was felt it wasn't needed or used widely enough to justify the implementation costs) or perhaps the feature was simply overlooked. Either way, only the team responsible for coming up with the design would be able to confirm this.

Kind Regards,

Martin.