Joel de Guzman

@redtide I think we should first target a feature branch and then merge to develop once stable. There are clients expecting a stable develop branch.

> Making a middle way change it's difficult to me, because there are cascading changes to apply that impacts Artist which in turn impacts to Elements, I have no idea...

> feature branch which has nothing new to see The binaries. Those are not vetted yet.

There currently is no way to do it. Take note that `audio_stream` is a thin wrapper over portaudio. Have a look at portaudio API. If portaudio API allows it, then...

> I initially used Portaudio in my project directly and I'm in the middle of migrating it to Q. There were no fancy buffer types, just an array of floats...

Alternatively, we can provide access to the data in the form of `T**` (e.g. `float**`). Is that what you were asking for? It's an easy tweak. The data is already...

> Portaudio doesn't allow you to read from a callback-based stream outside of the callback. Yes, that is expected. It's a real-time system. All real-time audio systems have similar interfaces....

> So from what I understand the only way to access sample data outside of the callback would be to copy the buffer somewhere else every time the callback is...

Can you explain a bit more? I have some concerns about the code changes. Thank you!

Thank you for your contribution. I appreciate it! Is it possible to move all platform-specific (Windows) code to `lib/host/windows/` ? In particular, `lib/include/elements/base_view.hpp`, `lib/include/elements/element/text.hpp`, `lib/src/element/text.cpp` should not contain any platform...