search

zardini123 / AnaMark-Tuning-Library

C++ library for interpreting and using AnaMark Tuning files (.tun V0.0 - V2.0), multiple scales files (.msf), and Scala files (.scl and .kbm).
https://www.mark-henning.de/am_downloads_eng.php
MIT License
14 stars 4 forks source link

Collaboration Opportunity? #2

Open baconpaul opened 4 years ago

baconpaul commented 4 years ago

Hi!

Thanks for making this code available.

Over in the surge synth team (the group that supports the open source Surge synthesizer - https://surge-synthesizer.github.io and https://surge-synth-team.org/) we factored the SCL/KBM parser I wrote for Surge into a standalone header only 100% test coverage modern C++ library. https://github.com/surge-synthesizer/tuning-library

We've used this library to make our tuning workbench synth, to add SCL/KBM support to dexed, and with surge 1.7.0 shipping Aug 1, to run the surge tuning.

The TUNv2 spec is enormous. I didn't want to try and support it. But a user pointed us today to this repo which contains the code.

I'm wondering if you would be interested in collaborating perhaps? Namely, take this TUN code and bring it into the tuning-library API format (so support the minimal client api, make it header only, etc... immediately 3 synths would get supported), run it against our test suite, etc....

I totally understand if that's not something you are interested in. And since you have kindly released your implementation under a very open license (which we also did with our lib - I picked MIT in purpose for the sub-lib even though Surge and Dexed which consume it are GPL3) I may allso just take a crack at it early this fall. But wanted to drop a note in any case!

Best

Paul

baconpaul commented 3 years ago

Ok I will fire up a windows vm and send a pr over

baconpaul commented 3 years ago

By the way I notice that Travis builds on windows with gcc. I don’t know anything about Travis but right now we build surge with 8 different compilers in our pipeline (2 visual studios, an Xcode, 3 gccs, a clang, and an arm cross compile) and also support a different clang and 2 arm natives. Can Travis add that easily too, or at least a subset? Visual studio on windows is probably the most important but the Linux gccs also vary more than you would like....

baconpaul commented 3 years ago

OK so I took a peek.

I don't have windows GCC but on windows with VS2019, the resulting executable from cmake appears in build\Release\anamark-tuning-test.exe. If that doesn't show up it means the cmake gcc environment is putting it somewhere else. I'd either switch to VS on windows, or alternately, do a recursive ls after the build to see where travis is putting it.

linux no clue. I just popped up ubuntu 20 and did

cmake -Bbuild
cmake --build build --config Release
./build/anamark-tuning-test

and it worked fine.

I wonder if travis is setting cwd on linux to something other than the source path? Its so hard to tell -there's really no log - but that linux message occurs if you have set a source tree incorrectly or if . doesn't contain CMakeLists.txt. Perhaps a thing to try is cmake -Bbuild . But like I said the error logs aren't that clear.

zardini123 commented 3 years ago

8 different compilers in our pipeline (2 visual studios, an Xcode, 3 gccs, a clang, and an arm cross compile)

Wait I'm confused. With this tuning library, we only need cmake, not gcc and clang, right?

Do you have an example azure config file so I can see if I can try figuring out if Travis has that capability?

I managed to get the windows build working, the linux is still giving issues. Cmake version on linux is on 3.12 whereas windows is on 3.17 and I think this is why because 3.13 of Cmake introduces the -B option as we know today. I'm having huge troubles trying to get cmake to update though.

baconpaul commented 3 years ago

https://github.com/surge-synthesizer/surge/blob/main/azure-pipelines.yml There’s the one that builds surge.

Surge pulls in tuning lib but tl is header only so doesn’t really have a make system.

If I was setting this up in azure I’d just use those variants though. Learned a lot by using clang gcc and Vscode all at once

zardini123 commented 3 years ago

Alright I got the config for the CI finally working! https://travis-ci.org/github/zardini123/AnaMark-Tuning-Library

My config is certainly jank for linux, as I do manually what cmake's -B option does automatically, but possibly some day this can be fixed if someone can figure out how to update make properly. I do have a great example travis.yml I found that I commented in this libraries travis.yml that shows how one can go about many different compiler versions. I have it linked here too: https://github.com/taocpp/PEGTL/blob/master/.travis.yml

Now next step is Doxygen CI and code coverage!

baconpaul commented 3 years ago

Ha - I am using PEGTL for a project in surge right now and yeah the use travis. If we can emulate the compiler support PEGTL has that would be wonderful!

zardini123 commented 3 years ago

The auto-deployed documentation is now live: https://zardini123.github.io/AnaMark-Tuning-Library/ I'll adjust the Travis config soon to only deploy the config when the master branch is updated.

Next step: code coverage

baconpaul commented 3 years ago

Great!

zardini123 commented 3 years ago

@baconpaul One problem I've been noticing about the tests while working on the CI is that the lookup of the testing .scl/.kbm files is relative. Therefore, the tests only pass if and only if the current directory is the project's root directory. Right now in my CI I am doing some extremely cringy current directory manipulation to be able to get the tests to pass. It'd be really great to be able to run the test executable from the build directory (or any directory) and have the executable find the test files.

EDIT: Actually, just pushed a new travis.yml test and I'm concluding that there is actually no way to compile the linux test coverage without having this directory issue in the tests themselves fixed. :(

baconpaul commented 3 years ago

sure we can add an environment variable for the test directory. Really easy to do. Is there a variable you prefer?

zardini123 commented 3 years ago

Ooo environment variables, good idea! I don't have any specific variable name in mind, but I think we should choose a prefix that we use for if we have more than one environment variable for some reason. I was thinking the prefix would be something like ANAMARK_. So then id think the variable name for the test asset (scale) directory would be like ANAMARK_TEST_ASSETS_DIRECTORY (probably something shorter).

baconpaul commented 3 years ago

I think that's a fine name. I'll add it to my list and fire a PR over next day or two OK?

zardini123 commented 3 years ago

That sounds great. Have you been working on other changes for this PR?

baconpaul commented 3 years ago

Lightly. The surge release was more involved than we thought and there's a load going on, but I do still have time in August to port over our tests, as discussed. On my list! And would be great to get tun support into surge. (Oh and here's a fun review of surge's SCL/KBM implementation, as well as our other tools!) http://www.synthtopia.com/content/2020/07/29/is-surge-the-ultimate-microtonal-synthesizer/

The env var change is attached in #10!

zardini123 commented 3 years ago

Alright code coverage and CI ready to go. The environment variable system works wonders. We do have to find a way to remove catch2 and the test files from the coverage report, but it's not critical at the moment.

Fun video you linked! Its very cool seeing people passionate about these tools. I'm hoping a concise tuning library will help foster better integration of tuning specs.

Also being we are close to hitting triple digits on this issue thread, I am thinking about starting a Discord server for this library so we and future users can come and chat about ideas, and also we developers have a good place to talk without having to flood the issue board. Does that sound good to you?

baconpaul commented 3 years ago

For surge we have a slack up and running which has proven critical. Seems you are thinking the same thing we have been for the last couple of years, just on alternate infrastructure! I don't use discord but I suppose I could!

baconpaul commented 3 years ago

Oh you are more than welcome to use our slack, by the way. Loads of microtonal musicians already there. Happy to make an "AnamarkTuning" channel on it. May save you a step?

zardini123 commented 3 years ago

Oh you are more than welcome to use our slack, by the way. Loads of microtonal musicians already there.

Oh that sounds fantastic! I'd love to join

When it comes to community servers, I've never seen Slack used outside the professional CS world. Every YouTuber I've seen with a community channel uses Discord. Inviting for discord servers s painless too, which is awesome. So therefore if we use discord for this library its easier for casuals, professionals, and Youtubers to join and participate in our work. So here, I made the server for this library, come join! https://discord.com/invite/4WXbgcx

I have the join link also as a badge in the readme. Its currently in develop branch

baconpaul commented 3 years ago

Great. Our slack link is on the surge synth homepage but here it is: https://join.slack.com/t/surgesynth/shared_invite/zt-godzc9wg-m~7b1GsOe4vENCgIJNrGYA

I think a lot of our users have slack open anyway for their professional stuff so it has worked well. There's a small IRC community over in linux land also. but I'm always on the slack.

zardini123 commented 3 years ago

Alright cool. So from now on let's continue this issue thread (discussion of collaboration) in the Discord server. Once everything in the "Ready for use in Surge Synth" project is completed, I will close this issue.

See you there!

mkruselj commented 3 years ago

And now we've basically moved to Discord from Slack, so... https://discord.gg/aPmbg7 🙂