@jcelerier here's the test and a mutex wrapped multiplex protocol that resolves the problem: ossia/libossia#795
i made it a Draft just cuz I thought you might have some other ideas as it is a lot different than what we talked about above..
i made it a Draft just cuz I thought you might have some other ideas as it is a lot different than what we talked about above..
I'm trying to build libossia for raspi.. I've done it a number of times in the past but now i'm running into an assembler error:
/home/pi/local/src/libossia/src/ossia/network/oscquery/oscquery_server.hpp:50:8: warning: by ‘virtual bool ossia::oscquery::oscquery_server_protocol::push(const ossia::net::parameter_base&, const ossia::value&)’ [-Woverloaded-virtual]
bool push(const net::parameter_base&, const ossia::value& v) override;
^~~~
{standard input}: Assembler messages:
{standard input}:605: Error: selected processor does not support `yield' in ARM modeI'm doing websearches to try to resolve it (maybe some cmake flags I can augment) but figured I'd check in to see if someone here has a quick solution
7 replies
@x37v while looking for solutions, I found this interesting thing re. thread safety: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
2 replies
the good thing is that the code can be annotated incrementally
I also fixed the failing multiplex test, but I think that I'm going to add some flags somewhere in the OSC protocol definitions so that people can define the behaviour they want more precisely, because the behaviour of "doing nothing when pushing from a SET parameter locally from C++ code on the server-side" is in multiple cases not what is wanted - whenever this came up I remember people saying that it was important to still see e.g. the value change in a remote UI when it is observed, just that this value change should not give a "deeper" notification and trigger actual events, etc. But the OSC message still has to go through to keep remote visualisation of live values up-to-date
1 reply
I was trying to improve performance of some use cases especially with the max bindings and noticed non-negligible time spent into regexes - a combination of RE2 (for user-supplied regexes e.g. for pattern match) and CTRE (for some internal fixed compile-time regexes) improves performance by a factor of 10 sometimes compared to std::regex
but CTRE does not work in C++17 mode with visual studio :| (it does with clang & gcc though)
it should still work without issues on ubuntu 20.04 & later
should be good, there's just this one which is a meaningful failure: https://github.com/ossia/libossia/runs/7763250870?check_suite_focus=true
this should enable some pretty good code simplifications
e.g. with c++20 we can remove all the operator== & stuff as the language can generate them automatically now
i'm currently making a semi-large change to enable new use cases: removing the CHAR type
which in almost ten years remains entirely unused in every score, patch, etc.. I've ever seen
it's being replaced by a much more useful type, a dict
so that we can have much better interoperability with json & the likes
heya, here's a test version of ossia max with some of the bugs reported this summer fixed @/all : https://we.tl/t-DcUEIGHxjR
it's a debug version so may be a fair bit slower than the release but will also yield better information if you get crashes as I'm not an expert in that codebase at all
RNBO was released today so I can finally link you all to the project I use libossia for: https://github.com/Cycling74/rnbo.oscquery.runner
@jcelerier I'm trying to build the latest master branch, i'm on osx 10.15.7 with xcode 11.7.. I'm wondering if I'm below the minimum supported version for libossia (and if that is listed somewhere)
it isn't building with errors about std::ssize, requiring initilalzation in constexpr, a few other things.. got it building with some changes that I can share though maybe I just need to upgrade
it isn't building with errors about std::ssize, requiring initilalzation in constexpr, a few other things.. got it building with some changes that I can share though maybe I just need to upgrade
BTW.. if you push an
nan rapidjson produces invalid json.. {"FULL_PATH":"/float","TYPE":"f","VALUE":NaN,"ACCESS":3,"CLIPMODE":"none"} .. clearly we should avoid nan but i wonder if it should not break json compatibility with other json parsers?
Wait for writing ? Hmmm
Can you make a couple GH issues? I'll look at it asap
What's the most common way to represent nans in JSON ? It's not part of the JSON spec no?
I can make some GH issues, no problem
I'll tag an rc2
weird