-
Notifications
You must be signed in to change notification settings - Fork 10
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
sf_phrase improvements #15
Comments
I like some of these ideas. I agree this string-fret combo functionality would get more use if the arguments did not have to be split apart. I for one would use it more than I do. There are some aspects and suggestions within your examples that would pose technical challenges. I also think some aspects are not cohesive enough with the rest of the package. But overall I support this idea. I will have to give it some thought (and find some time) so it won't happen as quickly as the last one which was a low-hanging fruit. What mainly needs to happen in terms of being able to provide a single string of information containing string numbers, fret numbers, and the remainder of the info, is that it needs to be unambiguously parsable into the three component pieces. Like currently, the string-fret approach piggybacks on Ideally there will be a chance for some strong assumptions that always work regarding splitting such strings into their three component parts. Again I'll have to really sit down and think about edge cases. But there is some possibility a delimiter would have to be introduced, frustratingly. But maybe not. As much as I like shortening all the typing as much as possible, I do intend for I'm still up in the air on string assumptions. I found that shorthand like Making note info interchangeable between whether it is provided along with string or fret would be problematic. I think the focus should be on making a wrapper API approach that simply allows all three components to be joined in each space-delimited time step, and that can map onto the current |
I forgot to mention re: string assumptions. One thing you seem to be proposing is carrying information about string numbers specified at one space-delimited point in time, over to subsequent time points. That would be an additional level of complexity. Of course it is doable, but I just want to point out for reference that currently the parsing logic is designed such that each time step can be parsed independently. There are no iterative operations performed in terms of the parsing of time step I imagine it would probably be easiest to tack onto last after the rest of the functionality was in place. For example, with each time step split out into its three pieces, I could then scan for those missing string information and apply some recycling/filling in. |
I know next to nothing about R but I made this attempt. It should accomplish goals 2-6.
|
I finally got this going. Sorry for the delay in reply, I have been busy with other things. But what you've shared here is a great help, being able to execute some examples. I was able to see the combination of suggestions more clearly. The version I have added on GitHub now is a bit different in approach and style but aims to fold in your suggestions. It is an alternative argument specification to An example:
I have written some unit tests, but this new input method could use additional testing before a CRAN release. I think this is a very useful approach though. I've leave this open for a while in case there are bugs I haven't found yet. |
Hey, I really appeciate your continued efforts on this project. This library is helping tremendously in my creative work. I think your solution makes sense here and satisfies the main concern. I had another idea that could be worth a try. Instead of single info or fret values, could we use a set, e.g.:
equivalent to:
|
Hi, I'm glad to hear you are finding use for the package. Your feedback has been very helpful as well. I see where you are coming from here, but I don't think this would be a good addition to But my primary issue is with consistent syntax rules and expectations. While At a minimum I want to maintain that for any given function or form of string input for creating phrases, a couple things hold true regarding timesteps. The input may look different for
This breaks a syntax property I really want to maintain consistently. But I also don't want to bind durations or other consecutive elements with another delimiter because each time step must be separated by a space. And we can both agree that adding more parentheses is no fun. I'll close this issue now. I think we've come a good way with the latest SuggestionI'm in favor of some string transformation functions in isolation. So, the From an R perspective, it's an obvious clean separation like between data manipulation and graphing or data prep and analysis; preparing the right syntax and then rendering sheet music. Abstract it away from So using your In fact when done from this perspective, I don't care what the original syntax looks like. I can keep the package from getting too complex or confusing, but I can offer any number of what are essentially API functions to |
While I respect your views on the importance of composing with musical notes, I still feel that sf_phrase is an important expedient, especially when writing in various tunings and positions. It can help me maintain creative flow without having to subject my ideas to theoretical analysis as they appear. It also can lower the barrier to entry for those who do not read music, which IMO can only good for tabr.
That said, the requirements of string/fret dual-entry concept seem to undermine the benefits of expediency for me, so I have a few suggestions that I feel would improve this.
Allow
r
,s
and~
symbols from one field to override the other.I feel that the improved writability justifies the potential confusion.
sfp("4*3", "0 2~ 2", "8. 16 2.")
sfp("4 4~ 4", "0 2 2", "8. 16 2.")
sfp("4*3", "0 r 2", "8. 16 2.")
sfp("4 r 3", "0 2 2", "8. 16 2.")
provide the option to do away with
string
, using positional string assignment.x
indicates muted strings.For tokens less than six characters, infer muted top
sf_phrase("x02030 2x0232 354","2 2 1")
specify the starting string.
allow these assignments to carry on to subsequent tokens
sf_phrase("3s987 775 553 232 5s757 545 325 6s2210","4")
equivalent to:
phrase <- sf_phrase("3s*4 543*3 6543","987 775 553 232 757 545 325 2210","4")
inline info tokens
let these also carry
sf_phrase("21","87-16*4 75-8 53 32")
equivalent to:
sf_phrase("21","87*4 75","16*4 8*3")
allow hex-like fret numbers
sf_phrase("6543","0a9b","4")
equivalent to:
sf_phrase("6543","0(10)9(11)","4")
put them all together
sf_phrase("3sa8~7~-8( 987-8) 775-4 5xx553*2 3s232-16*4 5s757-4r 545-4 325 6s22x0")
equivalent to:
phrase = sf_phrase("3~2~1 321*2 6321*2 321*4 r 543*2 653 ","(10)~8~7 987 775 5553*2 232*4 r 545 235 220","8( 8) 4*3 16*4 4*4")
The text was updated successfully, but these errors were encountered: