Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
maybites opened this issue Feb 15, 2019 · 49 comments

Comments

Projects
None yet
5 participants
@maybites
Copy link

commented Feb 15, 2019

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.

@maybites 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

@jcelerier

This comment has been minimized.

Copy link
Member

commented Feb 15, 2019

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

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 9, 2019

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

@bltzr

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

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

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 10, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 10, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 10, 2019

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

@bltzr

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

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

@bltzr

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 11, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 11, 2019

sorry, I am at a loss here.

I started afresh:

  1. a pull from the actual libossia repo
  2. changed the branch to 'ossia-max-fix'
  3. 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

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2019

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

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2019

@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

This comment has been minimized.

Copy link
Author

commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

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)

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

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

fixed with b21e0f5

@avilleret avilleret closed this Apr 18, 2019

@avilleret

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 20, 2019

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

steps to reproduce:

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

pressing the bang confirms this.

@avilleret

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2019

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

@avilleret avilleret reopened this Apr 20, 2019

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 21, 2019

I am pretty sure I have. the console shows:

build SHA : d96537e

@avilleret

This comment has been minimized.

Copy link
Contributor

commented Apr 21, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

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

@avilleret

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

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

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 23, 2019

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

@jln-

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 23, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

@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

This comment has been minimized.

Copy link
Author

commented Apr 24, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

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

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 24, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

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

@avilleret

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 24, 2019

OK, I got it:

I always tested the following way:

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

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

if you

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

it works.

it also works when you load it as a maxpat.

@avilleret

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

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 avilleret closed this Apr 26, 2019

@avilleret

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

@maybites the initialization seems to be fixed with a5c3c05

could you check it again one more time ?

@maybites

This comment has been minimized.

Copy link
Author

commented Apr 27, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.