Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 29 21:04

    jcelerier on ossia.cue.2

    [max] More work on ossia.cue [max] clang-format [max] More ossia.cue work and 1 more (compare)

  • Jan 29 17:02
    evanmtp labeled #820
  • Jan 29 17:02
    evanmtp assigned #820
  • Jan 29 17:02
    evanmtp opened #820
  • Jan 24 03:55

    jcelerier on ossia.cue.2

    [max] Improvmeents and bugfix t… [ossia.router] handle list inpu… [max] attribute autoregister and 4 more (compare)

  • Jan 24 03:55

    jcelerier on ossia.cue.2

    [max] attribute autoregister [max] Do not accidentally creat… [max] Router: allow to choose w… and 2 more (compare)

  • Jan 23 02:22

    jcelerier on master

    [util] Add an useful algorithm (compare)

  • Jan 21 01:26
    evanmtp edited #819
  • Jan 21 01:26
    evanmtp edited #819
  • Jan 21 01:23
    evanmtp edited #819
  • Jan 21 01:23
    evanmtp opened #819
  • Jan 20 22:41
    jcelerier commented #802
  • Jan 13 20:55

    jcelerier on ossia.cue.2

    [ossia.router] handle list inpu… (compare)

  • Jan 13 17:53
    bltzr edited #818
  • Jan 13 17:51
    bltzr opened #818
  • Jan 13 17:49
    vincentgoudard edited as member
  • Jan 12 21:30
    jcelerier commented #802
  • Jan 12 20:51
    navid commented #802
  • Jan 12 20:10
    jcelerier commented #802
  • Jan 11 21:24

    jcelerier on master

    [dmx] Allow 512 channels for dm… (compare)

Alex Norman
@x37v

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 mode

I'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
Jean-Michaël Celerier
@jcelerier
@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
Jean-Michaël Celerier
@jcelerier
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
Jean-Michaël Celerier
@jcelerier
oh these thread-safety annotations are incredible..
annotate.png
Jean-Michaël Celerier
@jcelerier
@/all is libossia itself being buildable only in c++20 mode (not c++17, and only building some libossia implementation details themselves) problematic ?
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)
Antoine Villeret
@avilleret
I think you can go ahead as long as it builds smoothly everywhere
Jean-Michaël Celerier
@jcelerier
yep i'm knee-deep into the CI ^^'
it should still work without issues on ubuntu 20.04 & later
Jean-Michaël Celerier
@jcelerier
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
Jean-Michaël Celerier
@jcelerier
(re. the above, it's still c++17 friendly but since no one complained.. :) )
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
Pia Baltazar
@bltzr
great !
Jean-Michaël Celerier
@jcelerier
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
Alex Norman
@x37v
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
Jean-Michaël Celerier
@jcelerier
Oh wow congrats, have only skimmed the press release so far but RNBO seems huuge!
Alex Norman
@x37v
thanks!
Alex Norman
@x37v
@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
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?
Jean-Michaël Celerier
@jcelerier
Ah, so in rapidjson there's a flag for enabling nan parsing I think
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?
Alex Norman
@x37v
yeah, i'm not sure about how to represent NaN.. i don't believe it is part of the spec
I can make some GH issues, no problem
Alex Norman
@x37v
Mathieu Chamagne
@matcham
Hello
does anyone have a recent build of ossia-max for Windows ?
(nightly builds are outdated, and latest release is getting old and doesn't contains the latest fixes..)
Jean-Michaël Celerier
@jcelerier
hello !
I'll tag an rc2
Mathieu Chamagne
@matcham
Thanks @jcelerier
but this rc2 doesn't seem to include the fix for remote @repetition 0
:-s
(tested on mac & win : the issue is still here)
Jean-Michaël Celerier
@jcelerier
hmmmm eird eird eird
weird