Anglo Piano webapp

[Luke Hillman]

7 hours ago, Richard Mellish said:

Taking the last point first; that's probably true, but this thread also serves as a useful survey of layouts, standard or non-standard.

 

I don't entirely agree that "once you move past 30-button and/or C/G layouts, there's basically no such thing as standard". Wheatstone and Jeffries are certainly pretty different. I can't confirm or correct your Jeffries chart, but I seem to remember from when I briefly picked up a 38-key Jeffries that it had less than 30 buttons in common with my (then one and only) Wheatstone.

 

However the Wheatstone-layout 40-key instruments are pretty consistent. I have three actual Wheatstones and two other makes, and I think all but my Bflat/F have exactly equivalent layouts, with everything transposed by corresponding amounts. (Though I can't check my D/A as it's currently away for an overhaul.)

 

My Bflat-F does have a few differences. Besides the one I that mentioned before, having a G on the right-hand end, top row, first button, push, there are two others. What would be the right-most button on the right-hand end, top row, is instead in the innermost row to make it easier to reach with my little finger That was at my request. But I've only just noticed, or been reminded of, one other difference. Left-hand end, top row, second button has a D on pull instead of the A-flat/G-sharp that would correspond to the B-flat on a C/G. I don't remember whether I requested that, but it was probably for the same reason as the G, for playing in G minor.

 

There was also one mistake in the chart that I attached. Right-hand end, top row, fourth button, pull, is an A-flat/G-sharp, as already shown on the stave and on your chart, not A natural.

 

A-ha! Good to know that button is G# on your instrument; that's one of the things that was bugging me. Yes, I agree that within the Wheatstone and Jeffries buckets, things are more or less standard. I suppose what I was speaking to was more that charts you're likely to find here and elsewhere (posted by people with particular playing styles and preferences, etc), never seem to agree exactly with each other, particularly in the less-common tunings. But I am having fun studying all the differences.

 

I absolutely see the value of moving the right-hand, top-row, far-right button to the bottom row. I have trouble enough reaching the top-right button on my 30b. One thing I hadn't really expected, as a person with a 30b concertina wanting to move up to a 40b one, is that the exercise of implementing and playing with all of them on a screen is giving me some (directional) ideas about what I might personally want in my next instrument.

[Luke Hillman]

On 1/3/2022 at 1:00 PM, Luke Hillman said:

@David Barnert I like the idea of using a soundfont. When I re-write the app from scratch, I could look at ways of doing that... for now, the easiest (if not simplest) things to try are using individual mp3s for each note (barf), or figuring out some way of using OscillatorNode (functional and performant, but not exactly easy on the ears).

 

Edit: I've just added piano sounds to the piano keys. It was tedious, and there's undoubtedly a better way of doing it, and I'm not sure how well it will work across browsers and devices. But it's something!

 

@DaveRo pointed out via email that an upside of using a tone generator as opposed to a soundfont/individual recordings is that it would be able to better support instruments with non-standard tunings. Due to the way the piano keys are matched to the concertina buttons in the app, I had to be consistent about naming notes (e.g., always using "G#" instead of "Ab"). I'll be thinking about this for future versions. In the meantime, if you're using a meantone-tuned instrument... I'm sorry! 😅

[David Barnert]

13 hours ago, Luke Hillman said:

I like not having to worry about ... the possibility that one day years from now some tool I rely on won't disappear from the internet without a trace.

 

There's no shortage of non-web apps that I relied on 15-25 years ago that no longer run on modern computers.

 

• BarFly
• ConcertWare
• MacDraw
• Microsoft QuickBasic
• MIDIBasic
• etc., etc.

Edited January 6, 2022 by David Barnert
Added list

[Roger Hare]

22 hours ago, Luke Hillman said:

.[1] ..I, too, prefer my software to run on my computer whenever possible...[2] I'd have to learn lots of

new stuff to make a native app, but that could be fun...

[1] Yes, you mention, or hint at, most of the reasons for liking (or not liking) web-based applications.

 

Which side of the fence one sits is a personal choice, I guess - my background means I'm a 'run

stuff at home' man.

 

I wasn't aware that some web-based programs can be ported to stand-alone status on a 'home'

machine. I'll keep an eye on that...

 

One of the main barriers to doing this is the reluctance of manufacturers to allow their customers

to run what software they like on the machines they have bought.

 

My current workhorse machine has only been connected to the internet for 5 minutes when I bought

it (6-7 months ago). This was only to turnoff 'secure' mode, so that I could run the software I wanted

to, not what Microsoft thought was good for me. Result - completely trouble free usage since Day 1.

 

[2] I'd have to learn lots of new stuff to write web=based programs... I tried Python - no thank you.

I thought about Java(Script), but a friend sent me the following, and I decided not to bother...

[JimR]

That image is hilarious.

[hjcjones]

On 1/6/2022 at 5:16 AM, Luke Hillman said:

At this point I'm just being obsessive; no doubt people with 38- and 40-button systems are already quite literate and will have little need of this tool 🤣

I wouldn't assume that. I learned by ear and don't know the note names which belong to most of the buttons.  After playing this particular instrument for some 35 years I can more or less find my way around it, but I still rely on trial and error a lot of the time so anything like this is helpful.

[Michael Eskin]

Web apps can be easily turned into standalone desktop applications using a number of technologies.  
 

The company I work for uses a freely available technology called “Electron”, which essentially uses Node.js and an embedded Chromium browser (essentially Chrome) combined with your web app code (HTML + CSS + JavaScript) to create Windows or Mac (but not mobile) installable native apps:

 

 https://www.electronjs.org

Similarly, on mobile, there are very easy ways to build an native app that creates a web view and then inject either remote or local web content.  
 

I did that for the WARBL wind controller iOS app:

 

https://apps.apple.com/us/app/warbl-configuration-tool/id1445377915
 

which wraps:

 

https://warbl.xyz/configure.html
 

My own concertina-related mobile apps for iOS and Android are not web-based, they are native and on iOS use the AVAudioEngine APIs for low latency audio playback, effects, and mixing:

 

http://appcordions.com/concertinas
 

Unfortunately, Android doesn’t provide a ubiquitous low latency audio graph API like AVAudioEngine, which is why I generally promote my iOS apps over the Android versions. I just can’t do on Android what I’m able to easily do on iOS, for example, there is no reverb available on my Android apps.
 

Recently I started experimenting with the newer low latency Web Audio API, available in essentially all modern browsers, even on mobile. It appears that it could be possible for me to port some of my native mobile apps to web apps using this API for the sound:

 

https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API

 

Of course, the question would be how to monetize and protect from piracy any web apps I’d want to sell rather than give away. It’s far easier to just let Apple/Google solve with all that for me via their App Store/Google Play stores using native mobile apps.

 

Edited January 9, 2022 by eskin

[Roger Hare]

15 hours ago, eskin said:

Web apps can be easily turned into standalone desktop applications using a number of technologies. etc...

That's fascinating, and answers in some detail a question I've been asking myself for 4- 5years now. Thanks!

 

Unfortunately, it ain't going to be me that tries it:

 

1) too long in the tooth to learn so much new stuff (the whole boilin, starting with JS...)

2) too much to do, not enough time to do it...

3) if it were to happen, my first choice would be the web-based utility I use for setting up Japanese Chess

situations - not very interesting for folks here...

4) miscellaneous other weasel-worded excuses for not getting my *rse in gear...

 

Seriously though, that is really really interesting. It will be nice to see it actually happen, but it really would need

someone with more technical knowledge in this area than myself - I can't even spell javerskript...

 

I do have a question: Does the process you outline result in a 'free-standing' executable, or does the machine

on which the program would be run have to have Java installed in some form (I couldn't quite work that out from

what you said in your post)? Thanks.

Edited January 10, 2022 by lachenal74693

[alex_holden]

2 hours ago, lachenal74693 said:

I do have a question: Does the process you outline result in a 'free-standing' executable, or does the machine

on which the program would be run have to have Java installed in some form (I couldn't quite work that out from

what you said in your post)? Thanks.

 

Yes. You might already be using Electron applications and not know it. It's popular precisely because it makes it easy for web developers to make cross platform desktop applications that ordinary users can install and use as if they were native. The desktop versions of Slack, Dropbox, WhatsApp, Microsoft Teams, VS Code, Skype, Discord, Twitch, 1Password, and many others use it. BTW it is written in Javascript not Java (the two languages are about as similar as concertinas and accordions - I'll let you decide which is which).

 

If you simply want to run a web app on your offline computer and don't care about it looking like a native application, the easier way is probably to download the code (if the developer has made it available), save it to a local folder, then point your web browser at that folder. You might run into issues if it tries to load some resources (e.g. images or fonts) from a web server somewhere, but it should be possible to download and save those files once, then modify the code to read the local files. [I should clarify - this is only possible with very simple apps that don't interact with a server at all, which is probably true of Anglo Piano.]

Edited January 10, 2022 by alex_holden

[Roger Hare]

1 hour ago, alex_holden said:

Yes. etc...

 

Thanks. That's extremely helpful!

 

The only one of the applications you mention which I use is DropBox.

 

I may well try the approach you suggest. I do have Java-something-or-other installed on one of my machines (it comes automatically with some of the programs I use from portableapps.com, I think).[1]

 

Thanks!

________

[1] So far though, I've been able to do  (more or less) what I want using other languages which don't require any hidden infrastructure when I move the

(executable) to another machine. This is more attractive to me.

[Michael Eskin]

7 hours ago, lachenal74693 said:

Thanks. That's extremely helpful!

 

The only one of the applications you mention which I use is DropBox.

 

I may well try the approach you suggest. I do have Java-something-or-other installed on one of my machines (it comes automatically with some of the programs I use from portableapps.com, I think).[1]

 

Thanks!

________

[1] So far though, I've been able to do  (more or less) what I want using other languages which don't require any hidden infrastructure when I move the

(executable) to another machine. This is more attractive to me.

You don’t need Java to run local web apps offline.

 

You just need for the app to not include or refer to any resources not on the local machine.

[Don Taylor]

1 hour ago, eskin said:

You just need for the app to not include or refer to any resources not on the local machine

Is it conceivable to create a local resource that served audio from a synthersizer like FluidSynth playing a concertina sound font?

[Michael Eskin]

I don't think so, but one could absolutely write some Javacript code to do low-latency audio sample playing and mixing locally entirely in the browser using the Web Audio API I mentioned above and per-note audio samples (which is what I use for my concertina apps).  This is exactly what I would do if I were to port one of my apps from native iOS to a web app.

If super low-latency isn't a requirement, you could easily use simple HTML <audio> tags to play locally hosted sounds when a button or other element is tapped.

Edited January 10, 2022 by eskin

[Luke Hillman]

4 minutes ago, eskin said:

If super low-latency isn't a requirement, you could easily use simple HTML <audio> tags to play locally hosted sounds when a button or other element is tapped.

 

@eskin this is what I'm doing on anglo piano, and unfortunately the sole method available to me using Axure. It seems to work relatively well if you're on desktop, but certain mobile browsers prevent buttons from playing audio unless the user clicks 'play' on that specific file's associated audio player (so a mobile Safari user would have to do this ~55 times before the piano keyboard would be fully audible, each time they loaded the page).

 

At the moment I don't have the expertise to fix this, but if anyone's interested in taking it on I'm happy to consult. I'm overjoyed at the amount of discussion this is provoking. Originally I hadn't even included sounds at all, because I mainly use the app while sitting at a piano 😀

 

In the meantime I'm working on adding all the "theoretically standard" layouts and the ability to customize them to suit individual needs. I spent a long time over the weekend trying to figure out how to allow a fully user-customized layout to be bookmarked (upstream commenters have correctly surmised that there's no communication with any server or database once the page has loaded, so I'm stuck using URL parameters), which wasn't quite possible, but I've got a workaround. Stay tuned...

[Roger Hare]

12 hours ago, eskin said:

You don’t need Java to run local web apps offline.

 

You just need for the app to not include or refer to any resources not on the local machine.

Good news. Thank you. Clearly, I need to look at this whole area in more detail than I have done

in the past. Thanks again!

[Luke Hillman]

Update: I've added the "theoretically standard" C/G, G/D, and Bb/F layouts. Reminder, if you've looked at Anglo Piano before, you'll need to hard-refresh the page (hold shift, click refresh) for it to work.

 

Since customization is so common, I've also added a hopefully-not-too-buggy layout editor and a way to get a link that goes directly to your customized layout so you can bookmark or share it—here's @Richard Mellish's customized Bb/F 40-button system by way of example (custom layouts will load rather slowly since it reads each note one at a time from the URL).

 

There are definitely some bugs that I'll continue to work on as I have time. If you run into anything major, let me know! I'm having fun working on this.

[Fanie]

Luke, it is great having sound on the concertina buttons.

Would it be possible to to make it that the corresponding piano key lights up when you push the concertina key?

Maybe that will teach me to master the piano accordion.

Thanks

[Luke Hillman]

On 2/7/2022 at 11:57 PM, Fanie said:

Luke, it is great having sound on the concertina buttons.

Would it be possible to to make it that the corresponding piano key lights up when you push the concertina key?

 

Glad you're enjoying!

I'm looking into this. For a couple silly reasons, this particular feature is rather difficult to implement. I'll keep thinking about it and hopefully will figure something out soon, along with a couple other things that've been bothering me...