REQUEST FOR INFORMATION. Durations greater than a quaver
twobob opened this issue · comments
How does one express a crotchet, minim, semibreve and moreover multiples of those for durations?
I tried the obvious "1" for a crochet and got an error about mixing formats.
Rather than report that (annoyingly) as a bug I am checking how would one would express it.
I am assuming it must be 1/1 for crotchet, 2/1 minim, 4/1 semibreve, 8/1 breve, 16/1 longa, et cetera.
Lets say Take is the command. How would one say
Start at "4 bars and 2 beats" and take "2 bars and 3 beats"
is it 9/2 5/2 ?
If so, that's pretty tortuous for the average user probably, I am not even sure the maths in that example would be correct and obviously some really fiddly values could result. :\ And that was a really easy example :\
perhaps some sort of shorthand? Maybe check for two periods in the string and do a Bars.Beats.Ticks conversion? Live works like that internally AFAIK, at least as far as the average user is concerned.
Possibly request for enhancement?
Also durations with a denominator over 9 don't work. Such as 12/2 or 11/1
Received 2 clips and formula: [0] shuf -by [1] take 2/1 10/1
Error: Unrecognized input at position 28:\r\n shuf -by [1] take 2/1 10/\r\n ^
That might be a bug
Also the loop size of the resulting clip seems to be short by exactly the original offset value, which might be a bug.
I'm just struggling with the concept of a decimal. Because I can't pass 12.75 or something directly
Received 2 clips and formula: [0] shuf -by [1] take 2/1 12.75
Error applying formula: Invalid option values: Values for a single option need to be of the same type.
Received 2 clips and formula: [0] shuf -by [1] take 5.25 12.75
Error applying formula: Invalid combination. Token of type Decimal and property of type Decimal[] are not compatible.
formula: [0] shuf -by [1] take 5.25 Fails silently.
I guess I'm just not quite there yet, I did look through the conversion code.
Ah good to know. thanks. I will note any tiny things like silent fails on the Take command to a separate issues and try to look at them as time allows, like yourself.
Okay I see the issue in the parser with > 1 digit numerator values is simply an indexOf issue. fair enough the b.b.t format thing seems doable, I shall look at it at some point then.
In terms of "discovering the token" properly
private bool IsMusicalDivision(out int SlashIndexInBuffer, int pos)
{
int NextSpace = pos;
SlashIndexInBuffer = 0;
string TestTheString = string.Empty;
while (!(NextSpace == Buffer.Length))
{
if (Char.IsWhiteSpace(Buffer[NextSpace]))
{ break; }
TestTheString += Buffer[NextSpace];
NextSpace++;
SlashIndexInBuffer = NextSpace - Position - 1;
}
string pattern = @"[0-9]+\/[0-9]+";
Match m = Regex.Match(TestTheString, pattern, RegexOptions.IgnoreCase);
return m.Success;
}
Obviously the call to that will honour the out like
else if (IsMusicalDivision(out OffsetOfFoundMusicalStart, Position))
{
token = new Token(MusicalDivision, GetRemainingNumericToken(
Position, OffsetOfFoundMusicalStart), Position);
}
where OffsetOfFoundMusicalStart is a locally scoped throwaway int.
(or a less pointlessly expansive version) would do the job for detection. But I think that would cover a fix?
I'll dig around and see if I can sure up the extant MusicalDivision detection before adding anything new like B B T.
Pattern matching seems relatively robust to offsets, confirmed this gives not insane values.
I'm actually working on doing MusicalDivisions properly now, along with a B.B.T format. Will report back :)
Thanks for looking into this. I'm probably going to refactor this section a bit though, and there's also some related parsing-logic which needs to be looked into. Might be I need to add some simple casting mechanics to get the various number formats working properly. It should for instance be possible to specify 12 as a musical value, which would be taken to mean 12 bars.
well. what I have now supports
Received 1 clips and formula: [0] rl 1001/975 rl 1/2
Which will do for now until there is something else. Excited to see what you come up with!
Many thanks for your time
Great!
Tests are looking good. Don't have time to test today, but have hopefully implemented implicit casting from i.e. number to musicaldivision. Also, parsing of musicaldivisions are now handled properly. Feel free to test if you have time to spare - it's on the branch feature/implicit-cast.
Thanks very much I'll grab it down and have a butchers
Just added support for input in the format beats.bars.sixteents (as used in Live) and tightened up casting logic. Not merged to master yet, so feature/implicit-cast is the place to be ;)
Now merged to master. Closing this issue :)