Hi Valentin, > 1) The user interface to this method is maybe not optimal. After all, this is > not a ready developed solution, but a quick test implementation. We do not > want to change the user interface if possible, as that breaks working scores. > So before pushing such a thing to master we should be convinced that the user > interface is good. > 2) The specific implementation should behave well in a way you can expect > that > it won’t break working scores. E.g. my tag-based solution might cause > problems > if some score were to use the same tags (thus one would need to make sure > that > the tags are specific enough that they wouldn’t get used accidentally for > something else.
Oh, of course… I just meant “Does anyone immediately see any obvious reason why this line of development shouldn’t be pursued to its [il]logical conclusion, with an eye to getting it into the codebase once it’s ready for prime time?” > you can clone the repo and add the changes. From there the discussion can be > continued. I’ll clone the repo and get things set up for moving forward. That being said, I think I’ll wait just a few days more for thoughts/discussion to gel on-list before diving into real coding. Thanks! Kieren. ________________________________ Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: [email protected]
