"open source" has a specific definition[0], which this project does not meet. When people say "open source", that is the definition that they are referencing. It's the reason why there's been endless discussion about "open weights" models not being "open source".

"source available"[1] is a different thing, and you're right that this project is "source available".

[0]: https://opensource.org/osd

[1]: https://en.wikipedia.org/wiki/Source-available_software

You are right. I've been corrected. I misunderstood their licence to be on the distributable, not the source. I'll take my misunderstanding home now.

Source available is not open source. Don’t try to redefine what open source means. It’s so insulting to volunteers hard work.

Apologies to every OSS contributor for my misunderstanding then.

How can you say its open source and 3 sentences later that it has a proprietary license.

Their EULA forbids distributing the software, hence not open source.

You are describing source available. That is not the same as open source.

Thanks, I see my mistake! Can't correct my post but I'll take this into future thinking.

This aligns pretty closely to the concept of a "flipped classroom" except for it's "flipped standup". Spend more time talking about getting unblocked instead the repetitive ceremony of "here's my update".

exactly the feeling I was going for. ;)

Hey! I'm an the Tambo team so I'll chip in. There isn't really any reason we couldn't support A2UI. It's a great way to allow models to describe generative UIs. We could add an A2UI renderer.

The way we elevator-pitch Tambo is "an agent that understands your UI" (which, admittedly, is not very descriptive on the implementation details). We've spent the time on allowing components (be that pre-existing or purpose-built) to be registered as tools that can be controlled and rendered either in-chat, or out within your larger application. The chat box shouldn't be the boundary.

Personally, my take on standards like A2UI is that they could prove useful but the models have to easily understand them or else you have to take up additional context explaining the protocol. Models already understand tool-calling so we're making use of that for now.

This would be really cool if I knew how to read tabs lol

I can think of a few improvements that could be fun to see;

- visual indicator for chord progression

- timing/tempo/click track for practice

- play the chord via audio output

- verify the chord via audio input

On a higher level, this is the sort of app/experience that really opens up learning to a whole new audience, particularly if there's no easy or affordable access to instructors. Nicely done!