Collaboration Opportunity? #2
Comments
|
Hi @baconpaul! I really appreciate you reaching out about this! One clarification I'd like to make before I respond is that I am not Mark Henning. I contacted Mark a couple months ago to be able to make Mark's library (which was originally available as a .zip on his website) a nice little repository (which is what you see here). It was Mark's decision to make it MIT, which I personally am extremely grateful for. The code you see in the repo today is not too far away from what Mark originally wrote that was distributed in the .zip since 2009. I think he really had some good ideas about implementation that makes the library still applicable and usable without any changes, eleven years later. Fun thing to note is that the API you all wrote for tuning-library is pretty similar to that of Mark's. For example you have a object that describes a single scale (your class Tuning, Mark's class CSingleScale). You both have functions for reading from a stream. Correct me if I'm wrong, but it seems tuning-library only has SCL/KBM read support, which is the same level of support for SCL/KBM as Mark's library. From that, we both don't have SCL/KBM write support, which I hope to add some day. You guys do have some nice utility functions for quick retuning that I don't remember seeing in Marks (but there is a reason why Mark's doesn't have many functions like that currently, and I'd have to explain on a separate occasion why, but a hint is because of TUN_Formula.h). You got the right idea that TUNv2 spec is crazy. To be able to support all possible TUN files is certainly not a 24 hour job (nor a week job), and one could guess this is why this library exists. Another clarification I'd like to make is that this is not just a TUN v2.0 library. It is capable of reading and writing TUN v0.0 - v2.0 (which includes v1.0). This also support MSF (multi scale tuning), which is an amazing feature for some certainly crazy xenharmonic music. My thoughts about the best course of action for everyone (for you and for fellow programmers wanting to have all possible tuning file support) would be to begin a very slow migration from tuning-library to this library, once a good deal of collaboration has been executed. With my statement about similarities in mind, Mark's current API for SCL/KBM is very similar to yours, which hits that checkbox for minimal API (for SCL/KBM at least). You have some cool ideas on what a tuning library should be, including being header only. A header-only paradigm could certainly help this libraries structure, as code is currently placed in odd ratios between .cpp and .h. You have some great tests for SCL/KBM already (yay catch2!) so much of that code could be transferred over easily. Some day in the future, I'd like to have tests for TUN and the sub functions as well. So in other words, instead of doing Anamark-Tuning-Library --> tuning-library, I recommend tuning-library --> Anamark-Tuning-Library. This change would be to ensure a quality library for TUN (v0.0 - v2.0), SCL, and KBM for years to come. From what I can tell, Mark didn't just write this library for parsing files, but a centralized library for xenharmonic and microtonal music. Of course I do not want to break any changes in API that your users use for your library, so during this migration, we could write a wrapper file of sorts for your repo to ensure no immediate breaking changes. Once we figure out details, I'd very much like to bring Mark on board to ensure his voice is heard with his own work. Conclusion: Yes, let's collaborate! But see all above :) Thank you, |
|
Yeah that's reasonable. There are some features of tuning-library I like (in order: header only, 100% test coverage, integrated with several synths already) which would be work to preserve and port. There's also a couple of really important things which it seems our library does - most notably handle midi notes from -256 to +256 - which are really key to make surge work. But I had indeed noticed the similar API when I read this. And we wrote tuning-library exactly for the reason you share namely a centralized MIT licensed library for microtonal music which implemented the full spec. And I have no particular pride about which direction we go (although would welcome you if you wanted to consolidate the effort for the final library with the rest of the folks in the surge synth team who have worked on our tuning apps - of course we can work that out some other time). So tell you what: I'm still getting ready to ship Surge 1.7.0. Let me take a look at this once we have that released in August. I am glad you are amenable. I think we really do need a single library to do this if we want commercial devs to support more robust tuning. Thank you! |
|
Yeah, get back to me once your complete with your update! This library certainly has the most complete implementation of the more popular scale types, so having you and your team expand and test this one would be the best time-to-results ratio. Just needs some tweaks, small QOL additions, and coverage.
Yeah though with TUN there is so much to account for so naturally coverage is gonna be time consuming. I think for SCL/KBM support in this repo its like less than 5% of the total codebase (I don't know, just guessing). Of course if we ever find that header only is not going to work with the complexity, your team could always fork our centralized library and make something to compile everything into a single header. Thats certainly something to discuss at a later date.
Yes! This is a change I wanted to make to Mark's library, but in a slightly different degree. Due to how most synths map midi note to scale note, Mark made the size of the scale frequencies constant at 128, which is very poor for very tight tunings. There is a technical reason why this is especially because of how the TUNv2 spec works, so implementation certainly would differ. So in some ways allowing "infinite" number of scale notes, but then mapping the midi notes to a small range (or any range), would allow -256 to +256. Would certainly allow versatility, nevertheless. Let me know the other important things when you get the chance. Thanks! |
|
yeah the outside-128 thing away from scl/kbm is tough. Things like Tunv1 and MTS give you the keys but don't give you a concept of a 'scale length' so you can't repeat. but lemme poke at the code after our release. I'm just happy you are interested in potentially working together. The lack of a 'once and well' library for tuning motivated our work in our library; and I think it remains important. |
Yeah that's what I thought. Do you have -256 +256 implemented in yours, or was that more of a hypothetical? |
|
We have it in ours and need it for surge |
|
Hi @baconpaul! Zardini123 asked me to join this discussion, as the GitHub repo is based on my .TUN specs and my library to handle these files. I support the idea of collaboration between both projects to get a versatile library and to make it as easy as possible to handle micro tuning for any synth developer. Putting all code in header files seems reasonable. Should be a diligent but routine piece of work for the .TUN lib. As for the MIDI note numbers ranging from -256 to +256: Just for my understanding. The standard 128 MIDI notes cover a range of 10 octaves + 8 semitones. Anyway, it should be possible to enhance the .TUN spec from 0 to 128 to the extended range from -256 to +256. The algorithms can be applied to that range. One has to care for the extended array bounds, loop start/end, read checks and so on. It is necessary to touch the file format, however. This is a bit tricky, because in my view, downwards compatibility is a major task and files with this extended range shall be readable by already existing synths. I can make a suggestion for a .TUN V2.1 spec which considers that range. However this may take a while because I will be on a vacation trip soon. |
|
Hi! Yeah the intent is to cover 42 octaves. (Practically we don't cover that much). Short version of why is: Surge has flexible modulation all over the place and models all of its pitches in keyboard space. So applying a very broad LFO to a note can easily push you off the end of the midi keyboard. It is rare we go beyond -50 or +200 but it is frequent to go beyond 0 and 128. Before I added microtonal support to surge it had an internal table which was (basically) 2^x from -256 to 256 which it used and then multiplied by 8.167etc... to get to frequency. |
|
@baconpaul: Is this a common standard or is that a surge-specific feature? Do common VST hosts support the MIDI note range -256 to 256? |
|
So the external midi range of all VIs is 0...128 (I don't know if MIDI 2 will change that but lets leave that be). But think about it like this. Imagine you set pitchbend range to +/-48 and play note 127 and bend all the way up. And imagine you are in a very "tight" tuning (like something extreme like ED2-96). That bend up will only cover half an octave of frequency but will internally require you to be able to resolve the note of inbound midi note [0,128] plus bend span. That's basically what surge (and what our implementation in dexed) has to do. So "in the presence of modulators, instruments generate notes which are outside the midi range" seems like a relatively common use case. But I haven't been inside the code of that many VIs. I think the real trick isn't to extend beyond 0,128 as much as it is to have the spec give the periodicity of the scale. With TUN we could just assume a periodicity of 128 if we had to, but the thing I really liked about SCL/KBM is that the scale periodicity and the keyboard assignment are separated, so you can logically think about instruments with much bigger keyboards. |
|
By the way, in .TUN, the periodicity of a scale can be set to any value you like. If you e.g. have a periodicity of 7 notes, just define note 0 .. 7, whereas notes 0 .. 6 contain the tuning and the value of note 7 specifies the periodicity. See the .TUN spec PDF section 3.6.1. .TUN also includes a separate keyboard mapping. See the .TUN spec PDF section 3.8. |
|
BTW^2: Keyboard mapping requires a functional tuning section. This is the most versatile way of tuning definition. |
|
Yes sorry I didn't mean to imply that TUN couldn't do that (I have only looked briefly at TUNv2 and realized it was "too big to implement" which is why i was excited to find this lib)! |
|
The idea behind TUNv2 was the following:
It is the same thing as with video encoders/decoders: The encoder does most of the work to allow easy implementation of the decoders for fast video playback. |
|
Yeah! I meant "too big for me to independently implement from the PDF on your website" not "too big for you to implement" - which is why I'm excited that the implementation lib is opensource (with, it seems, the same goal we had in surge land with making our SCL/KBM interpreter open source). BTW, if you get a chance take a look at our tuning workbench synth (https://surge-synth-team.org/ has it) which lets you do real time SCL/KBM edits while playing the synth. It's been handy way for us to think about tunings. But again in SCL/KBM format. |
I'm having some issues understanding how this metaphor applies to the TUN library, especially with that when it comes to MIDI note range. Currently the midi note range of [0, 127] is hard coded. Variable MaxNumOfNotes in TUN_Scale.cpp is used in function Apply in class CFormula to exit early if the scale note index is in the bound [0, MaxNumOfNotes). If a user needed something other than that (i.e. [-256, 256], they would have to manually edit the Apply function, and ensure any other function that deals with bounds is updated. Of course the current functionality follows section 3.6.1, but to me seems like an unfortunate hurdle. Providing an API to the user to set these bounds to whatever they desire would be perfect. I honestly think a TUN v2.1 spec with any definable bound (not just -256 +256) would be a great addition to an already powerful functional tuning system. With forwards and backwards compatibility in mind, TUN v2 and SCL would both benefit from it (just tile the scale), but TUN <v2 and MTS are stuck to [0,127]. Providing proper information, returns, and/or errors with functions to set the bounds would ensure TUN <v2 and MTS stay to their original spec, but allow the tillable scales to extend to infinity and beyond. |
|
Its certainly a good question about if other VST's already attempt a -256 +256 approach, or if surge is the only one. For my project Xen MIDI Retuner I need a variable bound other than [0,127] because my plugin works in frequency space, not MIDI space. My plugin calculates the frequency of the current midi note and pitch bend (assuming A=440, equal temp), finds the closest frequency that's in the scale provided, then outputs new midi notes and pitch bends to have the output midi produce a frequency that is that scale's frequency. This is great for users with perfect pitch (or good pitch) who have been taught with the chromatic piano system. A better explanation of how it works is provided in the Readme. Problem is that due to only having 128 scale notes, tight scales like 43 EDO only span like 3 octaves. Therefore only 3 octaves of the user's input snaps to usable pitches. I was imagining in the future library, one could define any bound for scale notes, for sake of argument -1205 to 5304. Calculation of the scale could be done in batches, and/or cached, so that it doesn't actually have to calculate (and store) 7000 scale notes, but calculates a single period (plus the outliers) and puts all accesses in that range (and multiples proper periodic constant (i.e. 2 for octave) to ensure its still periodic). There could be some utility functions for others working in frequency space to see when the scale starts exiting a usable frequency range (i.e. from less than Epsilon, to greater than half of sampling rate). Of course there is some edge cases of if the scale was a single note that never increases or decreases in frequency. This paragraph was simply in act of fostering thoughts and ideas for v2.1. |
|
Interesting convo Yeah surge and dexed both resolve midi note to frequency “late” and if you think about the mpe spec many others would also (mpe uses channel pitch bend with a very different granularity but is really just sending note concepts). So I guess it depends on what we think a tuning is! I always thought of it as a function from a continuous key number to a frequency. That key number has some Calibrating conventions (“middle c” is key 60 on halberstadt layouts say) but as controllers and protocols change it’s not clear to me that it has a natural upper or lower bound. |
Thinking of tuning as a function from a continuous key number to a frequency is certainly interesting, but I think is a bit odd. Pianos and keyboards have a direct mapping from key (midi note) to scale note. The layout of the keys repeats every 12 notes, just like the scale. This mapping is discrete, not continuous. Stringed instruments with no frets have the ability to not follow any scale if the player chooses, though one could assume they will fall into some sort of scale eventually because we humans fancy intervals (which scales inherit). Pitchbend in MIDI is used to bend between scale notes (usually for an ornamental sake), and could follow a similar argument to the string instrument argument. Scales/tunings themselves do not have a property that states "scale note 12.4 equals this pitch." For surge, are you just sampling the current midi note, the next midi note, and using pitchbend as an interpolator between the two? With that, I wouldn't correlate scales/tunings to continuous because of this interpolation. That interpolation is not a property of scales, and more of an ornament of natural music playing. Wikipedia considers scales to be "any set of musical notes ordered by fundamental frequency or pitch". The Oxford dictionary considers scales as "an arrangement of the notes in any system of music in ascending or descending order of pitch." Though this is now more of an argument about "is a set/arrangement continuous," but I think an everyman would consider an arrangement of flowers to not be 3.2 flowers. So in other words, scales got x number of frequencies (where x is an positive integer) per scale period. TUN v2 has a way to change a scale note's tuning at any period. Does the entire range of scale notes until the change happens counts as a single scale? Or is it a scale repeated with changes? 127 for midi notes exists because each byte of midi had a status bit, and seven data bits. I remember reading/hearing somewhere that the creators of MIDI were wanting to have much broader capabilities (i.e. higher baud rate meaning more data), but it would of made the hardware very expensive. Because hardware is cheap and software is super capable, I bet folks at MMA were like " 'bout time we make this upgrade" especially cuz of the rise of MPE and microtonal. It'd be fun to see if MIDI 2 is providing support for midi notes outside the range of [0, 127]. |
|
Ok, it seems that we are touching music theory now. Indeed, there is no need to limit the note range to -256 .. 256. We could also chose -32767 .. +32768. Neither memory nor disc space nor read/write/calculation time is critical in such dimensions. But does it make sense? How many notes are reasonably usable? As for the 43 EDO tuning: -256 .. 256 would span 12 octaves. Instead, the continous midi note number could be an alternative. Using e.g. aftertouch, one could simulate a note-specific pitch-bend while playing polyphonic. To have 1/8 notes, one could play the melody line with the right hand while the left uses a MIDI controller which sends specific aftertouch events. And what about MIDI sysex tuning messages? My synth AnaMark has an implementation for that, and this is some kind which is standardized since decades. If we try to create a "complete" tuning lib, we should consider this as well. As for the tuning workbench: Very interesting. If you implement TUNv2, you could also provide an interface using the functional tuning possibilities. This could give it a break-through as it would make it explorable. So, before getting lost in too many details: What would you think should be the next steps? |
|
Right yes! I think we all agree and can all find points to disagree about needlessly. Next steps is the right idea So my next step is ship surge 1.7.0 on August 1. Once that’s done there’s a few things we could do
That’s what I would do first And yes you exactly get the point of tws. Put the tuning modeling front and center in a synth in your daw. Having it support tun too would be great. Thoughts? If so we could get cracking in the late summer / early autumn! |
|
@baconpaul is the tuning workbench part of the UI of surge?
Whatever is best for your project!
The only utility functions that this lib has is all in CSingleScale. Those functions being Reset (Set scale to 12 EDO), InitEqual, and ResetKeyboardMapping. Oddly enough, none of these functions, nor the SCL/KBM import, deal with the CFormulas that are used by TUN v2 to calculate frequency. I think for forward compatibility sake (especially with the larger range request) we port those functions to use the functional tuning equations. So therefore I think this would be the best roadmap (very similar to yours, Paul):
|
Nope - a separate synth using the same lib. https://surge-synth-team.org/tuning-workbench-synth/ And your path sounds correct. I will point out that extended range for SCL/KBM is way easy so we could simply add a flag on the resulting scale supportsExtended and roll it out bit by bit also. And yes my utility functions are trivially small so the pros should be easy! I used 'catch2' for C++ testing and it worked like a charm, by the way. So I would probably add a step 0 to both our plans along the lines of "move all the source to a src/ and include/ directory; add LICENSE file; add a libs directory with catch2 in it; add a CMakeFile to build a test". I'm happy to do that if you want. Oh also we run on linux intel, linux arm, mac 64 bit and win 32 and 64 bit, so would need to make sure we can build and test in those situations. |
|
Oh and
the reason I started working on surge is because I got a roll seaboard 49, which I described to my friends as "a fretless piano" :) Where to put the inter-note interpolation we can figure out. Just we will need to interpolate somewhere to work in the VIs I've been working with. |
Actually the reason I begun working on my Xen MIDI Retuner is because I got a Seaboard. Funny how we both had ideas for it.
What dimension of interpolation are you using for surge? Interpolating by cents? Interpolating by hertz? Linearly interpolating between the two ratios? My earlier statement about how scales don't give enough info about what scale note 3.4 is is simply that, an assumption. The assumption I made for Xen MIDI Retuner is it will linearly interpolate using cents. This is fine for EDO, but some scales that have nice ratios (just/pythag/boilhen-pierce) may not be so nice anymore when 0.5 between two of the scale notes of nice ratios does not make a nice ratio. At a value of 0.5 we essentially have to smart-subdivide the scale. Unless we add to the TUN v2.1 spec a place to define how scales should be interpolated for pitch bend (i.e. be interpreted continuously), we should figure out the most accurate way to interpolate for a scale given. |
Yeah though like I said earlier, much of TUN v2 has [0, 127] hardcoded, so hunting down all the functions, changing/adding to the API a bit, and ensuring they don't explode is going to be a job even without making a new spec.
I'm liking the size of that list! Do you have a way to automate building/testing for all those architectures, or is it just telling fellow devs to run it on their systems?
Whoops actually I'm gonna add that right now.
Sure, sounds good! |
|
We use free Microsoft azure pipelines to build surge in Linux With gac 7 and 9 Mac windows with vs2017 32 and 64 but and vs2019 64 but and (as of a few days ago cross compiled) arm with every commit yes; and to automate the distribution of our binary. For the tuning library every commit and every pr builds the code and every pr runs all the tests before we merge. Easy to set up. I have done the same for rack and loads of folks copied my setup there too. |
|
Your interpolation question is spot on What I would really like to do is to have the interpolation as a trait or runtime option. I have not done that yet but we have a few interesting cases - especially with non monotonic mappings - where that might help. But I’ve not given any deep design thought to this yet |
Is there a specific reason you all use Microsoft Azure Pipelines? I know many open source projects on GitHub use Travis CLI, and to be frank I have never have seen Azure Pipelines used. I've heard that Travis has many great options for different environments (not sure if it has windows 64 and 32, but it has everything else). Travis is especially great being able to embed a badge that takes you straight to the public build information. I know there is some other options like CircleCI and Jenkins. Regardless whatever the CLI is, I'd rather not have it say its "free" but require a card on file, and then charge the crap out of us when we go outside their bounds (instead of just stopping what we're doing that's not considered free). For coverage, I've seen Codecov used extensively especially as it has a nice website for visualizing what needs to be covered. We should consider using that for checking coverage (and embedding a badge that provides that information). |
|
@baconpaul I begun setting up continuous integration for this library via Travis CI (see here https://travis-ci.org/github/zardini123/AnaMark-Tuning-Library). I do not know what arguments are required for builds of windows and linux to complete and then run the test executable, so I request your assistance on that. Soon I am going to also set up having Travis CI push the documentation to GitHub pages so the docs can be hosted right here on GitHub. I am also looking into code coverage and how to go about that. I'm still eyeing CodeCov. |
|
Looking at the outputs:
Is the travis configuration in git? If so I can look at that! |
Huh, crazy how a space changes things. Will adjust soon.
Yes the config is on git! Everything new is on the develop branch, including your changes. The file name is .travis.yml. |
|
Removing the space did not fix the issue. Running ./build/anamark-tuning-test.exe for windows also does not work. :( |
|
Ok I will fire up a windows vm and send a pr over |
|
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.... |
|
OK so I took a peek. I don't have windows GCC but on windows with VS2019, the resulting executable from cmake appears in linux no clue. I just popped up ubuntu 20 and did 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 |
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. |
|
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 |
|
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! |
|
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! |
|
The auto-deployed documentation is now live: https://zardini123.github.io/AnaMark-Tuning-Library/ Next step: code coverage |
|
Great! |
|
@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. :( |
|
sure we can add an environment variable for the test directory. Really easy to do. Is there a variable you prefer? |
|
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 |
|
I think that's a fine name. I'll add it to my list and fire a PR over next day or two OK? |
|
That sounds great. Have you been working on other changes for this PR? |
|
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! |
|
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? |
|
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! |
|
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? |
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 |
|
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. |
|
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! |
|
And now we've basically moved to Discord from Slack, so... https://discord.gg/aPmbg7 🙂 |
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
The text was updated successfully, but these errors were encountered: