How to compile FW

[lennylen]

Hi,

Really like my Bluebus but I wanted to make some minor changes to the firmware for the Bluebus UI/UX.. I'm totally new at this stuff, so please bear with me.

I've made the changes I was looking for in the firmware/application folder.. I'm not sure how to go about compiling the new firmware. I'd love to contribute, but of course, testing is required.

When I run make clean && make I get this error:

user:~/Documents/GitHub/BlueBusMod/firmware/application$ make clean && make
Makefile:113: nbproject/Makefile-variables.mk: No such file or directory
make: *** No rule to make target 'nbproject/Makefile-variables.mk'.  Stop.

Could someone kindly please post a step by step on what I need to do to actually compile this and how to load it onto the Bluebus after compilation?

Thank you

[tedsalmon]

@lennylen

Please refer to this issue — https://github.com/tedsalmon/BlueBus/issues/76

Thanks! -Ted

[lennylen]

Thanks for the swift response.

For anyone else reading this, I was able to install the MPLABS X IDE from their website. All I had to do was open the project and in the project directory use make clean && make and it successfully compiled the HEX binary in the "dist" folder inside the project.

Thanks @tedsalmon. I'm in experienced with this, I was curious if you could have a quick look at the changes I made to see if everything is OK? I don't mind contributing the changes, but they really just comes down to personal preference.

See the changes here: https://github.com/lennylen/BlueBusMod/commit/0eae5e21a715b8df7cc9c95790e9f57f81aaec81

Thoughts?

Thanks

[HDC67]

Your changes will work but you are removing functionality (the strings) and inverting existing functionality (play/pause) - as you say it's personal preference. Very unlikely you'll get these changes accepted.

If you really want set your preferences, you'd be better off making them a configurable option (defaulting to the current method). Even then I'm not sure Ted will want to get to that level of tweaking for these kinds of things.

Or just create a patch and apply it to whatever the current version is and build your own each time. Every now and then you may need to update your patch to apply it cleanly. Or just run your fork and rebase it off the parent to bring in anything new from the main repo. Basically the same thing.

[tedsalmon]

@lennylen

Thanks for sharing your changes! As @HDC67 mentioned, this is all very subjective. For example, I think inverting Pause / Play from the current state to the desired state is a war crime :P.

However, many artists and platforms (looking at YouTube Music) are slowly moving away from the "Album", so it makes sense that omitting this is becoming more widely popular. I'd be happy to include this as a UI setting where in you can stipulate different metadata options such as:

Title/Art./Alb
Title/Art.
Title

Now, I'm not asking you to do any of this, just spit balling how I would actually implement it. I'll probably add this to the list once 1.4.0 is squared away.

Thanks! -Ted

[lennylen]

For example, I think inverting Pause / Play from the current state to the desired state is a war crime :P.

Thanks @tedsalmon .. but can we at least talk about it? Lol.

When you playback music on any device, does it present you with a Pause button or the play button? Why should this be different?

However, many artists and platforms (looking at YouTube Music) are slowly moving away from the "Album", so it makes sense that omitting this is becoming more widely popular. I'd be happy to include this as a UI setting where in you can stipulate different metadata options such as:

Title/Art./Alb
Title/Art.
Title

I'd appreciate that.. thank you. Yes, removing the album would be ideal.

Not because I don't want to see the album.. but only because the real estate on the screen is so limited. So having that flexibility to choose between the 3 options there, that would be great.

That's also why I think the word "Bluetooth" on screen while metadata is being presented is redundant and inefficient. Is it really necessary to present the word Bluetooth and cram the rest of the metadata into the remaining space?

The changes I posted above didn't actually end up working out. I did get this to finally work if anyone in the community would like to use it.. https://github.com/lennylen/BlueBusMod/commit/6fb361f6d5a9a713d510203c3d4398ed045bb7ac

The changes:

• Show desired playback state instead of current playback state i.e. "Pause ||" button shown during playback instead of "Play >" button.
• Remove "Bluetooth" on display when displaying metadata to increase screen real estate
• Artist - Title format instead of Title - Artist - Album

There is a bug that when playback is paused, it shows Paused on the screen and it just stays like that even when playback is resumed. Not sure why though.

Please keep in mind that I have zero C experience, so I have no idea how to solve it. Any advice would be great but it's not a huge bug that bothers me a lot.

In a perfect world, I think the metadata should scroll back and forth instead of starting over when it reaches the end. But that's way beyond my noob abilities :laughing: .

[tedsalmon]

When you playback music on any device, does it present you with a Pause button or the play button? Why should this be different?

To lend you some credence, this UX makes more sense with the MID UI as the indicator is directly above the toggle. Both of my cars have Navigation, so it plays the role of a status indicator. I didn't want to change the logic per-UI, and at this point I quite like how it works.

I would be more than willing to accept a PR where you break this out into a configuration bit/byte that can be used to toggle the behavior on the MID.

That's also why I think the word "Bluetooth" on screen while metadata is being presented is redundant and inefficient. Is it really necessary to present the word Bluetooth and cram the rest of the metadata into the remaining space?

Previously, "Bluetooth" was statically pinned on the left, as this is standard for the radio UI. When I switched to the TEL UI, I got access to a lot more screen real estate as a giant blob rather than discreet screen spaces. It carried over but I didn't both to maintain "Bluetooth" statically on the left. Ideally, It should display "Bluetooth" at all times on the left, or even just "BT" to carry over from the OE functionality.

To be clear, I do not want to remove the "mode indicator", much like terrestrial radio shows AM/FM on the left. I am a bit unclear how RDS presents on a MID and I wasn't immediately able to find an example on YT, though.

There is a bug that when playback is paused, it shows Paused on the screen and it just stays like that even when playback is resumed. Not sure why though.

There's probably something wrong in the event handler for playback state. I'll have a look.

-Ted

[lennylen]

When you playback music on any device, does it present you with a Pause button or the play button? Why should this be different?

To lend you some credence, this UX makes more sense with the MID UI as the indicator is directly above the toggle. Both of my cars have Navigation, so it plays the role of a status indicator. I didn't want to change the logic per-UI, and at this point I quite like how it works.

Gotcha, yes.. you're using NAV, and I'm using MID.. I see now why we had some slight initial misalignment.

I would be more than willing to accept a PR where you break this out into a configuration bit/byte that can be used to toggle the behavior on the MID.

Hmm let me see if I could make that happen with my non-existent knowledge in C. It might be way out of my skillset but i'll play around with some stuff.

That's also why I think the word "Bluetooth" on screen while metadata is being presented is redundant and inefficient. Is it really necessary to present the word Bluetooth and cram the rest of the metadata into the remaining space?

Previously, "Bluetooth" was statically pinned on the left, as this is standard for the radio UI. When I switched to the TEL UI, I got access to a lot more screen real estate as a giant blob rather than discreet screen spaces. It carried over but I didn't both to maintain "Bluetooth" statically on the left. Ideally, It should display "Bluetooth" at all times on the left, or even just "BT" to carry over from the OE functionality.

To be clear, I do not want to remove the "mode indicator", much like terrestrial radio shows AM/FM on the left. I am a bit unclear how RDS presents on a MID and I wasn't immediately able to find an example on YT, though.

Got it.. so your vision with Bluebus.. Does OE functionality takes priority over user experience? Or can we find a happy medium?

Reason I ask is because when the metadata is being presented on the MID, it's constantly flashing due to limited screen real estate and quite distracting. My goal was to free up that space and reduce amount of flashing the metadata as it's quite distracting while driving. Hence, the reason I was looking to remove the Album info being presented with the metadata.

To answer your question regarding radio's OE functionality.. the MID's radio mode selector displays the RDS data is presented on the left side of the screen in chunks. And the transition between the chunks is very slow compared to the Bluebus chunks. It also displays a ST for stereo to the right of it.

I found a pic of it here. I will also confirm on my end if I can find a strong enough signal on my radio.

I was toying with the idea of moving the mode selector beside the MODE button.. However I see it's limited to 8 character based on how you have the lower menu sorted out in the current code. MODE takes up 4 characters leaving us with 4 more characters to us. So it would have to say "BT" on the lower menu beside the MODE button instead of "Bluetooth".

How is that idea landing on your end? 😛

There is a bug that when playback is paused, it shows Paused on the screen and it just stays like that even when playback is resumed. Not sure why though.

There's probably something wrong in the event handler for playback state. I'll have a look.

-Ted

Hey Ted, I appreciate that. Thanks for listening.