[ossia-max ]Feature Request: [ossia.parameter] keeping its value when [ossia.model] changes its address #478

maybites · 2019-02-15T16:20:36Z

Hi

Currently [ossia.parameter] is losing its value when [ossia.model] changes its address (see this topic)

I propose it should keep its value.

This is actually quite important, otherwise it is not possible to dynamically reassign addresses inside running patches without loosing the current parameters.

jcelerier · 2019-02-15T20:18:42Z

@matcham @bltzr I don't know why but I feel that this is relevant for you :)

maybites · 2019-04-09T13:05:29Z

Is there any chance you look into this and/or make a decision if this behavior should become part of the specification?

bltzr · 2019-04-10T08:08:02Z

I won't object to this - however I don't know how complicated this is to implement. I guess @avilleret only knows

maybites · 2019-04-10T09:35:51Z

well, I am very keen to see if I can implement ossia into SPARCK, but this feature is a prerequisite. without it it won't be possible.

bltzr · 2019-04-10T10:39:24Z

When this kind of case shows up in my own projects, when one particular feature isn't already there, and isn't completely obvious to implement either (maybe this one is, though, I have exactly 0 idea about this), my solution to make this happen is usually to find some budget on the said project, and to hire @avilleret to work upon it. Of course, this requires previous evaluation.
But that's also because I'm not such a C++ wizard - so, if you're fluent with C++, I guess you could ask for some guidance from @avilleret (and/or maybe @jcelerier) and we would all highly appreciate a pull request from you. :-)

maybites · 2019-04-10T10:57:40Z

You have a valid point.

I am happy to dive into the code with some guidance. I have experience with Max C-externals, but none with your frameworks architecture.

But before this can happen, a strategic decision has to be made by the framework architect.

avilleret · 2019-04-10T11:32:36Z

for the record, here is the patcher that have been posted on OSSIA forum :

----------begin_max5_patcher---------- 1830.3ocyZszaiaCD9r8uBBcpEvIPTurUOsaOVTrEnWyFXPKwXysRhBRzIN6 h8+d4K8zRNLdkRxgHEygjZlu4AGRN+X4BqczS3RKve.tCrXwOVtXgrIQCKz+ dgUJ5TTBpT1Mqrio6vEVqTjHwxFo691MtNUMliJPoXFtXKNCsKAK5hslFe3j rDLSNYvlFoGYUs5TOMrnCjr8aKvQLEK546cq8JfKbi3kus3oiys1f60iQMMr mywpAXYsBXsCks2BbunG+b4RwiUFJr6NxXzrgDV2IRXgWPXggsDVGupmiKrW uflhKKQ6wUBECeRxDVn33BNIP5y+C6.t3Oom9BWZG.PbBsFRncdsBsqMTHmP +P0KWCTwWkDOpcLz+MvNVoZ8breariyvOwEsyzt4f8X11LtPVlihFRsNQZ0. kDtApdEXjRs8zw0TJoSKdKrdfjfeDWTR39mMe7EVn77VMun0PDXx2nxIZyp5 lHYplrqap.+HoZ7d0shJ3BEiKQGKj7n0o.OqlogFiKxNRjrhpQt1QyRR8PCJ KCrvUWUjafIeaIxDJM5cCjuBr8avItddeBM5+vwsYYKZNNijky8TwYLDSy60 jiwOfNlv19.MiUR9tjCfbzeH5On4vAIJjAI6+4BBJoV.1WPhoYBlnilPzb0m 6NtqrxgtsvH6QFJefAyM93vxHDK4B4wxcnBghR6X5TQjQoIcIUOtD7CLM4bR VVOTjQyGmXAY+gKL1cTNwzKM2RJkaOlontkaSv1VhdrKZyPIIZm0tS+ITFIE wvLhRE3XWSTEb5PYTAMIoi7pn73.Th413Q3mHwrCxOTaiAd2I4UFQV0Z4Xxd bIqaaLz9xtsTxdVA5sZ53NsO7VFNMOgKEc6PmbPZ6v1NrVm1u3pWciwEkfQE .Nr1l5.Q3FMJ23Q5FKZGj645ys0U9wmGc+hKisnJ5tNFxUBIch32KpeAl6PE CJwLweifKqGEWfWKt3vydiiKtd1MQ49.hKvQPjfY.Q3KLxQDmPYvw.+OXHx2 S.kI73DiBI9WgyiykgDWnzFwIT5BYapyyp2GGnQvEmo2TA5q.lP49.V68dXp HEiQDY3nhr80Jx9ARIVlSjqc0yWTfaQNhllxSIpyxMR9NKFepUtZysECCj.1 MBv4BuBikWvIRuliaXCzYlOTqsX7gvOZyz6H448t6GY.lXOFhLCqKC2.+HuJ jY4q3DLewb+flvBGN.6.2L1hyN9WAh39BHh2ZAhDJiIGr9UFXYkXID1aF9DQ OlwpOimyfGuQgG+QgGuW.dBkKYoC7F.MCeDXxJcNLuwPTAmYvf9m.znGI1Dl mmZIJn5.cg1tuW44cobZb8l9jZzdPyZVMNSH9n3kw.nqIDi8KrA.I93a6bA. 5pxqq4bmRHYicfCRFRPeXnojdrHpRqnS6Ezk2hwkLRV8ovcWiKjniFoYd0Lg ugbgKbF4BGSYh4DJDQ0MhKDIR0qizhX04LCeeYsfw4L64gyDZDGS.MgH3NWp NAW.MfKBmS6m.Sse1LmbwZS4hf4jK17QviVFyBZpw4rxElfEyJTXbvs4jKL0 M0Yl4g2cuTSCUrdF4AiCTLi7P3udXBciU2Ypk3hwh2ptDvsHFqfriuQkx9WB 7q5xp1mP2gRzWEU8UYNvcYsrg4lnxn3RWwNbJuhcccSrd1JahuQX2FgSR1It F5gjlpiggu0xmTaltpjIF95m44xmzWhOGF3cp9xJc7ZOiCdmzCuq8wgMW0sS 6pKxlMaZAbstX01e2dWT943aBory15apnAtvDieP0M9FBWABBVIdIYklGpBg Y3luAV8G39qROVsCp9Vpegxv.1ADC7L8HHBkANvcEAzrjm4Ovf6nkkDzsh5c H4dvuQK.ORvO86fbbAP6Zca0jJBgHOCl1ZxV1JartTwzzQ492HFE7u38GSPE CqisufNVtix.0o343KO0J2VEhPG8Ib5JuFETUWEQfzm217iOILU.jLF3S5Rr f6T3NTolYMkkbjavF0NpWaVMGMo0aTKaGAXn9mO0JHN3qVetxLpDDi4yXANF fJAHfr2e0hCb7.0.9m6.NIm2mTpo1a0EnH2ATUzO2wcofN9dgBeq0gA1q2H9 uMgdP3FoqVM57qUKe5BfRcpO5BfpiI3DEd9kqiuufeZ7p3KXZVKB5IuV6ph3 ya8qc0HY+5dLMJouepIZL37Lk6bXDikORS5HmAyl9gfF7cBamvrUJINmx860 RVPn5DicjmJnaP8uZvpNa9+p4zPC3TXmTZGlU00iZqe7KBgAFvXNSfpxwPU0 agIQWdo6AOc0eXWSzv9SARF9FoxbcuJ2XU3idUBp3azqBP6U8mmW4miW0m8q 3S4NWTU+VuPV04v7WnTZJZ6Axdtnu+.SrAmBTVUz5pJsrKjfhh3oo0ZAKnJQ P+lrAqD8UZnsfOf9kgmUJelIUAQpPnQJL0k+b4+CspFij -----------end_max5_patcher-----------

I finally took the time to open it and understand what's wrong.

This is indeed an ossia-max issue, not a libossia one.
So if you want to use libossia in your SPARCK project through the C/C++ API then you shouldn't suffer from this issue.

Concerning the issue itself, it a registering issue, when we change the [ossia.model] address, the parameter is not registered correctly.

maybites · 2019-04-10T11:38:41Z

SPARCK is Max based, so I would use libossia through ossia-max.

bltzr · 2019-04-10T13:06:32Z

yes, so there's only stuff to change in ossia-max (and apparently in [ossia.model] I guess, probably around here)

bltzr · 2019-04-11T10:19:50Z

hey @maybites ! @avilleret began looking into this this morning on https://github.com/OSSIA/libossia/tree/ossia-max-fix - he said he would get back to it in 2 weeks or so... meanwhile, if you want to help to make this happen, you can try to compile this branch, since he couldn't test it (he only had a Linux machine, so no Max)

maybites · 2019-04-11T15:19:51Z

Hi
I tried to compile this branch, but run into the following errors (following this instructions) after the 'make -j8' command:

In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.cpp:7:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/device_base.cpp:4:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/client.cpp:9:
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.hpp:10:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/device.cpp:8:
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.hpp:10:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia_object.cpp:2:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/attribute.cpp:4:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/logger.cpp:5:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/object_base.cpp:7:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error:
no member named 'raw' in 'spdlog::details::log_msg'
std::string s(msg.raw.data(), msg.raw.size());
~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/client.cpp:260:31: warning:
expression result unused [-Wunused-value]
(connection_status+1, x->m_looking_for);
~~~~~~~~~~~~~~~~~^~
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/client.cpp:260:38: warning:
expression result unused [-Wunused-value]
(connection_status+1, x->m_looking_for);
~ ^~~~~~~~~~~~~
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/client.cpp:425:10: warning:
expression result unused [-Wunused-value]
(av+1, gensym(dev.name.c_str()));
~~^~
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/client.cpp:426:10: warning:
expression result unused [-Wunused-value]
(av+2, gensym(dev.host.c_str()));

jcelerier · 2019-04-11T16:46:17Z

hmm, if you started from an old clone you did a few months ago, you need to run git submodule update --init --recursive - the errors you get are because the spdlog library which is stored as a git submodule is not up-to-date.

maybites · 2019-04-11T17:43:20Z

sorry, I am at a loss here.

I started afresh:

a pull from the actual libossia repo
changed the branch to 'ossia-max-fix'
executed git submodule update --init --recursive inside the libossia folder

and followed the instructions from the wiki for building max on OSX.

the result of cmake ../libossia -DOSSIA_MAX_ONLY=1 -DCMAKE_INSTALL_PREFIX="$PWD/ossia-install":

-- The C compiler identification is AppleClang 10.0.0.10001145
-- The CXX compiler identification is AppleClang 10.0.0.10001145
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE  
CMake Warning (dev) at CMakeLists.txt:21 (set):
  implicitly converting '' to 'STRING' type.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Performing Test SUPPORTS_MISLEADING_INDENT_FLAG
-- Performing Test SUPPORTS_MISLEADING_INDENT_FLAG - Failed
-- Performing Test WL_ZDEFS_SUPPORTED
-- Performing Test WL_ZDEFS_SUPPORTED - Success
-- Performing Test GDB_INDEX_SUPPORTED
-- Performing Test GDB_INDEX_SUPPORTED - Failed
-- Update general OSSIA dependencies :
Synchronizing submodule url for '../3rdparty/CicmWrapper'
Synchronizing submodule url for '../3rdparty/GSL'
Synchronizing submodule url for '../3rdparty/RtMidi17'
Synchronizing submodule url for '../3rdparty/Servus'
Synchronizing submodule url for '../3rdparty/SmallFunction'
Synchronizing submodule url for '../3rdparty/asio'
Synchronizing submodule url for '../3rdparty/bitset2'
Synchronizing submodule url for '../3rdparty/brigand'
Synchronizing submodule url for '../3rdparty/chobo-shl'
Synchronizing submodule url for '../3rdparty/concurrentqueue'
Synchronizing submodule url for '../3rdparty/exprtk'
Synchronizing submodule url for '../3rdparty/flat'
Synchronizing submodule url for '../3rdparty/flat_hash_map'
Synchronizing submodule url for '../3rdparty/fmt'
Synchronizing submodule url for '../3rdparty/frozen'
Synchronizing submodule url for '../3rdparty/hopscotch-map'
Synchronizing submodule url for '../3rdparty/libartnet'
Synchronizing submodule url for '../3rdparty/max-sdk'
Synchronizing submodule url for '../3rdparty/multi_index'
Synchronizing submodule url for '../3rdparty/multi_index/third_party/brigand'
Synchronizing submodule url for '../3rdparty/nano-signal-slot'
Synchronizing submodule url for '../3rdparty/oscpack'
Synchronizing submodule url for '../3rdparty/pure-data'
Synchronizing submodule url for '../3rdparty/pybind11'
Synchronizing submodule url for '../3rdparty/pybind11/tools/clang'
Synchronizing submodule url for '../3rdparty/rapidjson'
Synchronizing submodule url for '../3rdparty/rapidjson/thirdparty/gtest'
Synchronizing submodule url for '../3rdparty/readerwriterqueue'
Synchronizing submodule url for '../3rdparty/spdlog'
Synchronizing submodule url for '../3rdparty/tbb'
Synchronizing submodule url for '../3rdparty/variant'
Synchronizing submodule url for '../3rdparty/verdigris'
Synchronizing submodule url for '../3rdparty/weakjack'
Synchronizing submodule url for '../3rdparty/websocketpp'
Synchronizing submodule url for '../3rdparty/whereami'
Synchronizing submodule url for '../3rdparty/wiiuse'
Synchronizing submodule url for 'cmake-modules'
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/GSL
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/chobo-shl
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/hopscotch-map
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/nano-signal-slot
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/brigand
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/whereami
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/rapidjson
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/readerwriterqueue
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/websocketpp
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/asio
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/variant
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/spdlog
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/fmt
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/SmallFunction
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/Servus
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/bitset2
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/concurrentqueue
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/tbb
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/exprtk
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/flat_hash_map
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/multi_index
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/frozen
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/weakjack
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/verdigris
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/flat
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/Servus
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/oscpack
 -> /Users/maybites/Arbeiten/02_code/library/ossia/libossia/CMake/cmake-modules
-- ...done
-- Boost version: 1.69.0
-- Found DNSSD: /System/Library/Frameworks/System.framework  
-- Found ZeroConf in /usr/include;/System/Library/Frameworks/System.framework
-- cotire 1.7.10 loaded.
-- Build against git revision : 29abad17, last commit on 2019-04-11
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Looking for MaxSDK into : /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/max-sdk/source
-- Max/MSP SDK Found at: /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/max-sdk/source
-- Found Max/MSP SDK Headers at: /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/max-sdk/source/c74support/max-includes; /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/max-sdk/source/c74support/msp-includes
-- Found Max/MSP SDK Frameworks at: /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/max-sdk/source/c74support/max-includes/MaxAPI.framework; /Users/maybites/Arbeiten/02_code/library/ossia/libossia/3rdparty/max-sdk/source/c74support/msp-includes/MaxAudioAPI.framework
--  Files.h have been found here : /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/Headers
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- OSSIA - Build Type: 
-- OSSIA - Sanitize: OFF
-- OSSIA - Tidy: OFF
-- OSSIA - Static: 1
-- OSSIA - Coverage: OFF
-- OSSIA - Examples: OFF
-- OSSIA - Tests: OFF
-- OSSIA - CI: OFF
-- OSSIA - Framework: OFF
-- OSSIA - Dataflow: OFF
-- OSSIA - Editor: OFF
-- OSSIA - Protocols: OSC;Minuit;OSCQuery
-- OSSIA - Zeroconf: 
-- OSSIA - LTO: OFF
-- OSSIA - OSX Architectures: 1
-- OSSIA - OSX Retrocompatibility: OFF

-- OSSIA - bindings ----------
-- OSSIA - PureData: OFF
-- OSSIA - Max: 1
-- OSSIA - Python: 0
-- OSSIA - Unity3d: 0
-- OSSIA - Java: 0
-- OSSIA - Qt: 0
-- OSSIA - C: 0
-- OSSIA - CPP: 0
-- Jack_INCLUDE_DIR : 
-- Configuring done
CMake Warning (dev):
  Policy CMP0068 is not set: RPATH settings on macOS do not affect
  install_name.  Run "cmake --help-policy CMP0068" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

  For compatibility with older versions of CMake, the install_name fields for
  the following targets are still affected by RPATH settings:

   ossia-max

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: /Users/maybites/Arbeiten/02_code/library/ossia/build-max

but then with make -j8 I still get

/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error: 
      no member named 'raw' in 'spdlog::details::log_msg'
        std::string s(msg.raw.data(), msg.raw.size());
                      ~~~ ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:43: error: 
      no member named 'raw' in 'spdlog::details::log_msg'
        std::string s(msg.raw.data(), msg.raw.size());
                                      ~~~ ^
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/client.cpp:9:
In file included from /Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.hpp:10:
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/ossia-max.hpp:52:27: error: 
      no member named 'raw' in 'spdlog::details::log_msg'
        std::string s(msg.raw.data(), msg.raw.size());

etc..

avilleret · 2019-04-12T08:25:53Z

I made those changes blindly because I don't have OSX nor windows boxes under the hand for now.
But the issue you got is strange. You might need to sync the submodule too with :

git submodule sync --recursive

I'll try to build it next week.

jcelerier · 2019-04-12T08:39:29Z

hmm maybe the ossia-max code is not up-to-date. sadly I don't have access to a windows or a mac until sunday so I can't test until then either - will keep you posted

avilleret · 2019-04-12T08:47:38Z

As shown on Travis the issue @maybites is facing to was here before my changes and maybe since a while.

maybites · 2019-04-12T08:55:53Z

the member 'raw' was removed from spdlog::details::log_msg last october in the following commit:

gabime/spdlog@6355e98#diff-e467d3a37f5898269f0d711eb188e9bb

could you verify against which commit of spdlog you are compiling? I tried to compile agains a commit before the removal of the member 'raw', but now its complaining

no member named 'payload' in 'spdlog::details::log_msg'

avilleret · 2019-04-12T09:07:35Z

@maybites the issue here is that libossia have been updated to use latest spdlog code but not the ossia-max binding.
I'm currently trying to fix it.

avilleret · 2019-04-12T10:29:21Z

@maybites I just pushed a fix, could you pull and try to build again (don't forget to revert spdlog to the version used in the repo, git submodule update should do it for you)

maybites · 2019-04-12T10:41:01Z

ok, the spdlog errors are gone, now there are these:

/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:48:25: error: no
      member named 'pd' in namespace 'ossia'
         nodes = ossia::pd::find_global_nodes(addr+"/");
                 ~~~~~~~^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:54:22: error: no
      member named 'pd' in namespace 'ossia'
      nodes = ossia::pd::find_global_nodes(addr);
              ~~~~~~~^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:73:26: error: no
      member named 'pd' in namespace 'ossia'
    std::pair<int,ossia::pd::model*> model{};
                  ~~~~~~~^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:73:36: error: 
      expected expression
    std::pair<int,ossia::pd::model*> model{};
                                   ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:73:43: error: 
      expected unqualified-id
    std::pair<int,ossia::pd::model*> model{};
                                          ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:74:26: error: no
      member named 'pd' in namespace 'ossia'
    std::pair<int,ossia::pd::view*> view{};
                  ~~~~~~~^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:74:35: error: 
      expected expression
    std::pair<int,ossia::pd::view*> view{};
                                  ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:74:41: error: 
      expected unqualified-id
    std::pair<int,ossia::pd::view*> view{};
                                        ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:87:13: error: 
      cannot use dot operator on a type
        view.second = find_parent_box_alive<ossia::max::view>(
            ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:91:12: error: 
      'view' does not refer to a value
      if (!view.second)
           ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/view.hpp:12:7: note: 
      declared here
class view : public object_base // FIXME why view doesn't inherite from ossia::max::node_base ??
      ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:93:14: error: 
      cannot use dot operator on a type
        model.second = find_parent_box_alive<ossia::max::model>(
             ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:98:67: error: 
      'model' does not refer to a value
    std::vector<std::pair<int, object_base*>> vec{device, client, model, view};
                                                                  ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/model.hpp:12:7: note: 
      declared here
class model : public node_base
      ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:98:74: error: 
      'view' does not refer to a value
    std::vector<std::pair<int, object_base*>> vec{device, client, model, view};
                                                                         ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/view.hpp:12:7: note: 
      declared here
class view : public object_base // FIXME why view doesn't inherite from ossia::max::node_base ??
      ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:106:20: error: 
      assigning to 'std::vector<t_matcher> *' from incompatible type
      'std::vector<std::shared_ptr<t_matcher> > *'
        matchers = &p.second->m_matchers;
                   ^~~~~~~~~~~~~~~~~~~~~
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:114:23: error: 
      use of undeclared identifier 'ossia_pd'
      tmp.push_back({&ossia_pd::get_default_device()->get_root_node(),
                      ^
/Users/maybites/Arbeiten/02_code/library/ossia/libossia/OSSIA/ossia-max/src/utils.cpp:128:42: error: 
      address of overloaded function 'ossia_register' does not match required type
      'void *(void *, ...)'
  x->m_reg_clock = clock_new(x, (method) ossia_register);

avilleret · 2019-04-17T21:42:55Z

ossia-max build is now working again (and the ossia-max-fix branch have been merged into master)
but there is still an issue with default value which are not fired when first registering a parameter
this happens both when creating the parameter (see #441)
and also when changing model's address (which internally trigs a new registration process)

I'll look into that first
then I'll try to find a way to keep the value when changing model's address.
For the second, the issue is that the parameter is internally destroyed and then recreated when we change the model address, so we have to keep a copy of its value(s) before deleting it and restore it (them) after.
This value should be filled with default value when creating the parameter (or when loading the patcher)

WIP on #478

maybites · 2019-04-18T12:10:34Z

I was able to compile as well, still have some compile warnings, but the externals seems to work.

Really appreciate your efforts here. I assume you keep this thread updated on the above mentioned fixes.

avilleret · 2019-04-18T21:25:12Z

fixed with b21e0f5

avilleret · 2019-04-19T06:41:15Z

this seems to be fixed now, but it was not tested extensively, in particular I didn't test with nested model.
I mean it's worth testing changing the address of a root model that contains another model with parameters.
It's also worth testing with wildcard parameters such as [ossia.parameter foo.{1-3}].
I only tested within a VM and an unregistered Max 7 (I can't save anything).

maybites · 2019-04-20T17:19:10Z

@avilleret I tested the latest master (d96537e) with this example and it still doesn't behave as I would expect:

steps to reproduce:

select 'address myNewBoxName'
enter value for parameter
select 'namespace' and verify the value is set.
select 'address myOtherBoxName'
select 'namespace' and verify the value is set. - > but it is 0.

pressing the bang confirms this.

avilleret · 2019-04-20T20:31:53Z

this is strange @maybites, I use the same example here and it works both in Mac OS VM and on Windows 10.
Could you double check that the commit shown in the Max console is the one from which you build ?
It should appear when you instantiate the first ossia object.
And I will double check on my side

maybites · 2019-04-21T06:45:11Z

I am pretty sure I have. the console shows:

build SHA : d96537e

avilleret · 2019-04-21T21:37:37Z

This is very strange. I don't understand. Here is a video of what I got on my desktop MacOS machine.
(I hope it is readable enough, I forgot I have a 4k display...)
https://youtu.be/BhzqCovuv4o
Note that I'm using Max 7.3.5 32bit and I got the same result with 64bit version.

maybites · 2019-04-22T08:28:10Z

I compiled the latest: build SHA : 0c00d79 and tried both on Max8 and Max7 32 bit but it still doesn't work on my machine as on you video. can you provide me your compiled package?

avilleret · 2019-04-22T10:51:51Z

@maybites here is my build : https://framadrop.org/r/uv4LQsgJtU#Q9+SCf7hGlwTumwmuc9lHUYtEGsyC9iFlfNK4nQV9NU=
let me know

maybites · 2019-04-22T11:10:40Z

@avilleret your package is not working on my machine either.. And I made pretty sure I use your code. very strange. I don't have a working theory at the moment.

avilleret · 2019-04-22T12:29:54Z

would be useful to get some feedback from other users.
@matcham, @jln- and @bltzr could you give it a try ?
btw @maybites do you notice other strange behavior with ossia-max ?

bltzr · 2019-04-22T14:24:43Z

it seems to be working (I used the build from framadop above) Max 7.3.5 OS 10.14.2

https://files.gitter.im/OSSIA/uYG3/testModel.mp4

bltzr · 2019-04-22T14:26:45Z

I also tried with remotes and everything seemed to go just fine

avilleret · 2019-04-22T15:31:34Z

@maybites do you have another computer under the hand to test on by any chance ?

maybites · 2019-04-23T10:15:52Z

I just tried it on a pristine machine with osx 10.12.6 / Max 8.0.5 64bit with the same effect.

jln- · 2019-04-23T10:53:09Z

Just tried @avilleret 's build with Max 8.0.4 (64 bit) on macOS 10.13.6 and the example by @maybites works fine (parameter does keep its value when model's name changes)

maybites · 2019-04-23T11:32:18Z

@jln @avilleret this is all very strange. I just wanted to test it on windows, but it looks as if you haven't got a max-windows solution for libossia, yet. Is this correct?

avilleret · 2019-04-24T09:16:49Z

@maybites there is a ossia-max package for windows, both 32 and 64bit
you can download CI build on appveyor, here for example : https://ci.appveyor.com/api/buildjobs/yb7x7aa184dnokps/artifacts/ossia-max-win.zip
or build it yourself if you're fearless

maybites · 2019-04-24T12:18:22Z

I am fearless but also very unsuccessful and unable to build max for win by myself (I was able to build up to the Visual Studio solution, but didn't progress any further than that). @avilleret your link doesn't contain a working max-package (at least I couldn't find it). there are some mxe-files, but they cause an error 126 inside max7 32bit.

avilleret · 2019-04-24T12:43:13Z

you're right there is something wrong with the packaging script... I'll upload my build asap
and also open an issue to fix the script...

avilleret · 2019-04-24T14:19:43Z

here is my handmade Windows package @maybites
https://framadrop.org/r/b_-GIczO0C#33cSWr7JHq2A/qlkZG6QIKfw5EenGwJJlaSOeCHC0rk=
@matcham might be interested in also

maybites · 2019-04-24T15:31:11Z

still the same effect. Just to make sure we talk about the same thing, here another max patch with step by step description and the expected results:


----------begin_max5_patcher----------
2005.3oc2assjahCD8Y6uBU7VpxiKj3lIOrUx939P1OfLobICZrIADTf7LdR
p7uu5BX.atYrYhmcpxdLpEntOR8QsjZ907YZahOPxz.eD7UvrY+Z9rYxhDEL
K+5YZQ3Cdg3LY0z7hihHTl1BkLF4.SVNbIHiDR7X.J4E.12Okjk8HEIJlAdF
Gtm.heBjfSwQDFI8QpAWzt3WTxxDBobQYIXOxiTyk.ucX5VRwiRHOJ1mD9H0
ZIXCWDHdeSOXvC+EfbHgqID+OBX6Hk0As7CORsauYO+V4MQBuU3UxX4GJr4v
.JwKdOUZ314ElfYd6BnaWmxucEfZZ5tTeA.ZarzZAv.YJtZkyRcv2xuI59n.
ZHgIgVXdgA9R.Mdy2e.tRqrlbconp5hB+874huVLvNNQO0l8LVL8r9Nas1MB
aSKgZqTdj72P2JlvlsdwgwopJquz00V2YkoAzvAYY5tfWjkQs+DEIdHUdFob
vzmHMaQCLPrwrYrw3nsjOfXMgh2DRj3VtLU0YulPT5sl1B0m.Qm52tsnqUGn
q0J26Tz03cB5Z1A5ZpeuN1E8NAcM5.cMzMtSQW36DzE0A5htaG6p+NAcgcgt
n6Svc08D1xiJJCukbFvdLdo9CaP8sihn.0VjOnyABqlABXqF6nrPdnp7F6LC
jAB6m2yEVLroKSqg9Xy2FSaezFRZ+DLpdHK8K1LLZYNLzXGqJhoeb1ZcBf1C
ypVnrlWhsZzce1EYqi2NaygrXIRQu9u7Esj92wG9BWc5OvHEd.stb2Sj68wf
XCmpKwZDihgV2MihagLJArkvVODNW0jZPGIwjgt9E2qNhN0pZCIM25xMuYZO
EDRdljlEv8NKePyzvIIUJdVkaQfIeWMy6pEGKJfpJR+XQojmCJte6ikhS4XB
iCH6Sk5n1A6B1VwiI1mjR2GHUEUg7dmbUR1OThxRZEd2Ug3JbI51R5eoSigs
7e1B+oBvPD9PXr2OTy8WnxZwIDZ.Mg6nRnLLKW2OJ1m7DdeHa8SwTVVvOkZ.
DsrQ4OkqgMJTXCR0+yoA3viFv1z.+XpPIp0SHJtn49JmJPQHT0Xj0fhSZ3l4
iY3vRKBy3F49rM3TQGUtmCpPHKNNrtni2WH4IVt3j.J8DTjEmztvzfs653d2
DyEF00yVJIa8dpR5Z9XB15L7y0QaFNLL2Ys9i+.lFDgYDVfpK.oeTnh8XWlW
ZbXXM6UI44Fj3yGi6QdIvmsS1PUGLvqdPRwfHsi8x9AaIYr5kwvaypWRF6UE
nWon8ax8gWyHQIgbqndEpsQgUcXqRqUq7Nm7pNGmWHAmB3vZUoMvvkyyCUNe
mS22JKWaLcsy104zXyJX2y4PFIjTiw+DV+TB2gxWt4o7O8fK7UkH2hQS8Rpo
twEXy3hy6EbA1GhXqKPDjqjQy1ZzHh88Nh7yPPVHmmnWHw.p1FZWoKj93cdr
ZGRPcBIK9y3.0GohkBXbkqKvwbzCUP2ECUjpYOlrkszhsUAJV7c6FrdyFLb7
FbEwEmnT0oajMD0mbnRrZS8HF9p9Aa5C3TdMFtkH2nFpX.uBenJKw3dxOxz7
F4Fs58xjP58wrrBdalDB47+q3UJnbu53UP28SOygCvFvC8M4LzzQfHtRJYam
wCHcL4rwfHVpsiwSO9HOH8i6wSqviqbFqbhWaX+3iUK3iY63iYW3i.SVzzlp
O8PTJWYHfS2AntmhBZIIfg5FiNLO38SbdCIllbOnqNnFCy2lnZP2P7QoK8E+
uiZORQCEfZK1kNFWnesw0UtuShrrokMbPZbB4MCMYw6S8J5UxiSET2N8IYr.
5wcg6qki3EUbP8LWrRXMPsv.NgZAZnJwTBEBR3AoEh3dNohwo9p8YF9mU0ra
WyzmFMSzifFBnILAiopqSnEvAnEtS43G6gN9Y0TpENCUKrmRsX08fGsjyBNz
AmSpVLDrXRghAStMkZwPcSQSrN7G2KcnTENSnNLXhhITGbudZh7BKNyTMwAi
4uVcHfqwLVZvF9BUxN8PfunCqZaX7FbX9QQc7nLa3rrlWpbugo0Tdt+L5zZB
9lj1DeOfsziDFtQbLzEsXqmMLOP8viGxHxTu2rlSk7H4IXfY0bdqgCmtYHIM
9E0pz0a.iraFjLqzHmeB4BqnVSbFVFFjUaI7kYuPkiksxSym7j5N4qsbAv1d
g3eRat7KUNf0bwO.K9.91sLgPhyxBvKKeeGhdcc4EeRXvf.JC7o7jBfiQFCH
CZLPxUOq6b4IBV2YPSWaOvsDPjubHBvP8iOUg1A7n1mA4bJY.eB+IlR7A3L.
N+cJQiCbbpE.u41QBS30IJtwW2CTuoeCxth2gQkToPqVNkBKxjTGYxkJ90JW
SHbU8rHsOvG8lPnzehm8ExK8m1YJDJOqyLctX1S6qxXkMS8sUPY6mNUZNBbd
jc0V7bayeVN84Yf7PaH2AzNvZA1nEE3mDyc6ypdVuH8UxAgkWbkJl8.TLzM.
.FBP6dCZGig.zV2BCx8MB4LLdiFiZNbCpv8r1N2LoMra0U+btugbpNHRMiWk
qNWU0uJUEN.U07FzWXMp1QwGdRpXJZhSRAySR+xyS8x1S6xSS4R4RGToe1Ib
vGiL8evQwQ306B1xs7s6XhUXjJdQPUb+Eo5XcDA64QnrJyuBUghYU88xXd4Z
WDo0K+FNMO3zh3O4fh98BDpkLCc9um+e.Pnhwe.
-----------end_max5_patcher-----------

avilleret · 2019-04-24T19:20:43Z

I got the result described in the comment. Sorry for that...
Could you make a screencast of what you get ?

avilleret · 2019-04-24T19:25:37Z

one thing to note : I can't save the patcher into a file and open it.
I only copy compressed code and make "New patcher from clipboard".
That might make a difference.
@maybites could you attach a .maxpat file (in a .zip archive) directly here so I can test by opening a patcher instead of creating new objects ?

maybites · 2019-04-24T19:49:22Z

OK, I got it:

I always tested the following way:

copied the code (select + cmd-c)
opened a new patcher
pasted the code (cmd-v)

when you do that you will see my experience I had so far.

if you

copied the code (select + cmd-c)
Menu > File > New from Clipboard

it works.

it also works when you load it as a maxpat.

avilleret · 2019-04-26T11:37:10Z

ha ok, so it seems there is still an initialization issue which is not related to this one
so I'm closing it and re-open the relevant one

avilleret · 2019-04-26T19:07:25Z

@maybites the initialization seems to be fixed with a5c3c05

could you check it again one more time ?

maybites · 2019-04-27T16:30:22Z

@avilleret I can confirm, the issue seems to be resolved. But I haven't tested nested models and special parameters yet.

maybites changed the title ~~Feature Request: [ossia.parameter] keeping its value when [ossia.model] changes its address~~ [ossia-max ]Feature Request: [ossia.parameter] keeping its value when [ossia.model] changes its address Feb 15, 2019

avilleret added a commit that referenced this issue Apr 18, 2019

[ossia-pd] save parameter state before deleting parent model

64fe50c

WIP on #478

avilleret closed this as completed Apr 18, 2019

avilleret reopened this Apr 20, 2019

avilleret closed this as completed Apr 26, 2019

[ossia-max ]Feature Request: [ossia.parameter] keeping its value when [ossia.model] changes its address #478

[ossia-max ]Feature Request: [ossia.parameter] keeping its value when [ossia.model] changes its address #478

Comments

maybites commented Feb 15, 2019 • edited

jcelerier commented Feb 15, 2019

maybites commented Apr 9, 2019

bltzr commented Apr 10, 2019

maybites commented Apr 10, 2019

bltzr commented Apr 10, 2019

maybites commented Apr 10, 2019

avilleret commented Apr 10, 2019

maybites commented Apr 10, 2019

bltzr commented Apr 10, 2019

bltzr commented Apr 11, 2019

maybites commented Apr 11, 2019

jcelerier commented Apr 11, 2019

maybites commented Apr 11, 2019

avilleret commented Apr 12, 2019

jcelerier commented Apr 12, 2019

avilleret commented Apr 12, 2019

maybites commented Apr 12, 2019

avilleret commented Apr 12, 2019

avilleret commented Apr 12, 2019

maybites commented Apr 12, 2019

avilleret commented Apr 17, 2019 • edited

maybites commented Apr 18, 2019

avilleret commented Apr 18, 2019

avilleret commented Apr 19, 2019

maybites commented Apr 20, 2019

avilleret commented Apr 20, 2019

maybites commented Apr 21, 2019

avilleret commented Apr 21, 2019

maybites commented Apr 22, 2019

avilleret commented Apr 22, 2019

maybites commented Apr 22, 2019

avilleret commented Apr 22, 2019

bltzr commented Apr 22, 2019

bltzr commented Apr 22, 2019

avilleret commented Apr 22, 2019 • edited

maybites commented Apr 23, 2019

jln- commented Apr 23, 2019

maybites commented Apr 23, 2019

avilleret commented Apr 24, 2019

maybites commented Apr 24, 2019

avilleret commented Apr 24, 2019

avilleret commented Apr 24, 2019 • edited

maybites commented Apr 24, 2019

avilleret commented Apr 24, 2019

avilleret commented Apr 24, 2019 • edited

maybites commented Apr 24, 2019

avilleret commented Apr 26, 2019

avilleret commented Apr 26, 2019

maybites commented Apr 27, 2019

maybites commented Feb 15, 2019 •

edited

avilleret commented Apr 17, 2019 •

edited

avilleret commented Apr 22, 2019 •

edited

avilleret commented Apr 24, 2019 •

edited

avilleret commented Apr 24, 2019 •

edited