Cherry Audio Forums

I would like to input units when editing a component value, so that I can for example type 1 m for a minute or 60 s for 60 seconds when inputing a value for a knob that controls duration.

Does anybody have any tips about how to do this? I mean how to parse the input to get the double and the string values from what is typed in so that I can then do something depending on what the string part is, which I'm guessing is what I would need to do, but it's not clear to me how to do this.

Any help would be appreciated.

Well, sadly no one responded to this post, even though I know this is something pretty trivial for those of you who know how to do it.

Maybe people are not very active here anymore, or the ones who know weren't looking, or maybe they just don't feel like sharing this type of information, for whatever reason. But I think the more accessible this info is, the easier it will be for people to make better modules, and thus the platform will grow and we will all benefit.

So in the spirit of sharing, here's the answer I came up with to make this work, in case somebody else will find it useful.

You can access the string part of the input when you type something like "10 m" as the input using newText. Then you can check if it contains the character you specified as a condition to scale the values. Something like this works:

if (newText.contains("m")) {
newValue = newValue * 60;
} else if (newText.contains("h")) {
newValue = newValue * 3600;
}

Cheers!

Thanks for the tips.
VM specific tips are good for everyone.

<code>
newText = newText.toLowerCase();
</code>
Putting it before "if" statement can make the process case-insensitive.

Yeah, there's no place to really look some of these things up (specific to MD), and questions of this type tend to just go unanswered, so I think it's good to share whatever little tips we can.

Great job with the vary-step sequencer by the way!

Yeah, thanks!

Sometimes, explaining those technical things is slightly difficult and takes much time.
I will try to put little tips when I have something useful.

I realize that this thread is long dead, but I thought I'd at least try to bring it back to the realm of the Undead, but Not Unanswered.

Were I approaching this problem (and I might be, shortly), I'd use Java's regex facility to specify a more complete syntax when verifying the answer, instead of just searching on a single character, which leaves too much leeway for the user to feed in a set of symbols that can fool the verifier into accepting as valid something that really isn't. I've got a coffee mug covered in soi disant computer axioms and adages; one of them goes something like, "If you design an input editor that can't pass bad input, an ingenious idiot will figure out a way to get bad input past it." That said, it's still a good idea to make your inputs as stable as possible.

I'd supply an example, but my working knowledge is based on Perl-style regexes as used in C\C++ and modules like PCRE. I haven't really looked at Java's take on regexes, just know that they're there; I'd hand you a mess for sure if I tried blind.

Reid

I don't use the java.util.regex.Pattern class because it looks too powerful and complex for this task.

So I use the java.util.Scanner class instead. It does all the basic parsing stuff without you needing a deep understanding of regular expressions.

As an aside, anyone not already familiar with Bachus-Naur form might want to check it out. It's an easy to understand metalanguage that should be part of every programmer's mental toolkit IMHO.

Here's the wiki page on BNF, it's not brilliantly written but still serves as a useful introduction...

https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form

Once you get comfortable with BNF you can describe syntax in a simple yet formal fashion and it's straightforward to then map the metalanguage onto methods using something like the Java Scanner class.

Interesting stuff, Colin. I wasn't aware of the java.util.Scanner class. While I do savvy BNF, I savvy regexes more, having done a lot with them. So, for me, it's probably an example of "If your only tool is a hammer, all your problems look like nails." (The converse is pretty funny, too.) Guess it's time for me to expand my toolkit a bit.

Reid

I suspect Scanner is actually just a user friendly wrapper for Pattern.

If you come from a Perl background then regex will seem like a natural tool but to most generalist programmers it's going to look scary.

I came across BNF via Chomsky long before Perl emerged and it was so easy to understand that it led to a deep interest in language design and implementation. Being able to quickly design a simple problem-specific custom language and knock up a compiler or interpreter in a day or two from boilerplate is a very useful skill. It was my "secret weapon" for several decades.

By the way pure BNF is arguably over reliant on recursion, so in practice most people use some form of extended BNF to make life easier. But one should understand BNF first as its metasyntax is so simple. Then quickly move to EBNF.

Roger that. I came to BNF through formal language and parsing study, especially as I've always had a big interest in natural language parsing. I also had to get to know it better when I implemented language support for several languages in one of the commercial program editors. Writing a full-blown parser using just regexes would be something of a beast, but it's really pretty trivial for a simple input filter. The only thing that makes regular expressions frightening for most people is the difficulty of reading complex expressions. Well, and you do have to know how they work at a fairly basic level to avoid surprises (and to understand just why certain expressions even exist). What I guess I'm trying to say is that once you've learned it, and admittedly, it has a pretty steep learning curve (verging on asymptotic, it seemed at times ), it's easy to use in lots of situations. For example, the expression
looks pretty beastly, for all that it's pretty short, but once you come to terms with the specific subexpressions it's using, you can see what it does. I won't try to turn this into some kind of guessing game; it recursively finds matching pairs of parentheses in its input, a fairly useful and basic thing. Once you've done this sort of thing a lot, you'll have a pretty good library of such snippets you can reuse. In fact, I reused that one by going into the editor I mentioned and snagging it from the program's repository of such expressions. A good book on regexes is Mastering Regular Expressions on the O'Reilley imprint.

I came to Chomsky sometime in the late 1970's when I picked up Aspects of the Theory of Syntax on a whim. It's been interesting to see all the changes in his theory over the years. I didn't learn BNF or any sort of EBNF from him, though, but from compiler books. Holub's Compiler Design in C is a particularly readable one, especially compared to the Dragon books.

But I digress...and digress...and digress...wups, time to pop stack!

Reid