Bongo Cat(bongo.cat) |
- ability to save played melodies,
- ranked playlist.
Not the same people necessarily, but the same community.
(I'm musically illiterate but I assume that, except for the meow, all instruments from this site follows the usual music rules. Sorry if what I just written is nonsense)
Quick google search also reveals a few libraries [0] that should help.
The 1 should be one semitone lower, but it's still decent. Contra Walken, there is in fact too much cowbell if you try to play it simultaneously.
Now back to lurking.
You're welcome ^_^
Otherwise the browser assumes the page didn't do anything with the events and uses its default keyboard handlers. I have find-as-you-type enabled, and pressing keys launches search for me. Handlers need to "eat" the keyboard events to prevent default browser behavior.
edit: oh it's on github, gonna submit an issue
backtick code comments/snippets from source text are. really not widely standardized, I don't think it makes sense to encourage them without an accompanying web standard, or at least some kind of standard
let e = $.Event('keyup'); '09090586 '.split('').map((k, i) => {setTimeout(()=>{$.play(InstrumentPerKeyEnum[k],k,e.type==="keydown")}, i * 200); setTimeout(() => {$.play(InstrumentPerKeyEnum[k],k,e.type==="keyup")}, i * 250)});
I think this is checked regularly, but I'm not sure.
See also: https://www.youtube.com/watch?v=lT1Rowl-EFM
:D
Right now you can only play the first 10 notes (semitones) of the chromatic scale so it makes it a little unusable musically.
It would be awesome and playable if it was:
- All 12 semitones plus octave (13 notes total)
or if limited space for buttons is an issue
- 7 notes of a major scale plus octave (8 notes total)
https://play.google.com/store/apps/details?id=com.castlewrat...
0 9 0 9 0 5 - 8 6 3
1 1 3 1 - 6 5
1 1 3 1 - 8 6
1 1 1 0 - 6 5 3
1 1 0 6 8 6
- modified a bit, as only 10 of 12 notes are reachable.
Thanks for the fun distraction for a few minutes :)
I would love to be able to upload a midi to this...
Back in 2006, a while after the passing of my previous cat (Kira), I became the new subordinate of two six week old sibling tuxedo kittens, Buzz (male) and Blossom (female). They were pre-named by the cat rescue place and I didn't have any better ideas, and so those names stuck for a while. Explaining "Blossom" was sometimes a challenge if you know me, 20st at the time, petrol head, beer, curry, other things, but do love cats.
Anyway, Buzz grew into this almost 5ft long (but not fat, or overweight) slightly clumsy cat in his "teens"; there was a laptop flooded by a glass of water, a not inexpensive B&W speaker broken by an attempted leap (grrr)...usual cat stuff.
Privately I started calling him "Bongo", I don't know why, it just seemed appropriate, and suited him. I also started calling Blossom, his sister mini-bongo around the house, but then mini-puss. Blossom was the runt of the litter (there were three cats in the photo, I offered to take all of them, Buzz was the middle cat, Blossom was the tiny one).
Anyway just a story.
Sadly Bongo (Buzz) passed away due to kidney issues at the age of 10 back in 2014. I miss him, he was so good natured (as is Blossom) and an amazing lump of feline friendlyness, seeing this today brought a wee tear to my eye.
Anyway, some links to these awesome pals:
https://imgur.com/bMr725m ("Bongo")
https://imgur.com/YGZZOAW (Younger days)
https://imgur.com/oq124oJ ("Bongo...again")
https://imgur.com/Fsgmqsd (When Buzz broke into a bag of paperwork when I left the house for a couple of hours)
https://imgur.com/NZLsF59 (They still managed to squeeze into their kitten bed somehow even after five years)
https://imgur.com/voqjl0F (Blossom, pretty much today, a bit of a lopsided sit, but 14 and a half years old and still as crazy as ever).
This is reversed for the Piano and Marimba for some reason which I think should be fixed.
Online tools I've found present note in all octaves, which I found confusing. So I've created own tool — no frameworks, 5603 bytes, entire code displayed on the page (except soundfont-player library).
The DOM API is so much nicer than the native one it’s not even funny.
And when you are not dealing with thousands of buttons you realize you don’t need a virtual DOM. You may even come to the conclusion that if you have so much state in a single view, maybe your UI sucks.
And that beneath all the React hype, there were people doing “components“ and “server side rendering” in PHP, Python, Ruby, Java for decades.
But I’m not gonna get grumpy this early in the morning.
Apart from work things the main example would be a that I built a small audio sequencer hacked together with Vue. That project would've been suicidal to do in JQuery but also went far quicker to make than if i would've been messing around with doing everything "properly" in React. (Iirc the entire thing is <1000 loc)
My main "issue" right now is if i should just leave it and let it be useful at the current level (perfect for creating small retro-style chip tunes with fixed audio channel tone generator controls). Or to remake it in React to enable more easily supporting stuff like view plugins (to control parameters custom instrument/filter plugins), I.e. in principle making it more "application" like rather than just a small one-page hack.
Personally I've never known anyone do this for any other reason but educational reasons. When I wanted to learn React, I copied other websites in React. I do similar things when I'm learning Golang, or C, or any other language I'm interested in.
Struggle to imagine any React/Redux engineer I know getting this on the screen in even 3 seconds let alone sub 1. Depresses me how even 10 second webpage load times are considered acceptable in that toolchain, I know it's capable of better but it clearly needs more work to get there than people are willing to put in.
Observed "in the wild":
C » C++
C++ » C++ w. STL
C++ » C#
VB » VB.NET
WinForms » WPF » Silverlight » UWP
Edited to add:
Java EJBs » Java Servlets » Java Spring
C++ » Java » C#
Contrast that to writing for the Windows Platform--you could easily choose one of many languages.
My poor little internet points <\3 sorry HN for the unforgivable offense of asking a benign question
Thanks
I've seen Backbone.js, Angular, React, etc, all come and go and none ever answered the “why would I want that” question to me. I remember using Prototype.js and MooTools.js and when I saw jQuery's home page I knew instantly the “why” and the answer was an instant and rejoicing “yes”.
I never spent much time on webdev in the era where jQuery came into being but as I've understood (and from the jQuery code I've seen since) it solved basic issues in working with manipulating the DOM and gives powerful animation tools,etc. So as you say the upgrade over the browser API DOM manipulation is obvious, clear and direct.
I'd say that my background is mainly from games, where you usually setup your own data structures and then rendered them as it fit.
From time to time I've worked on custom tools on native platforms (win32/GDI/MFC, Java/Swing,etc) and working with these is conceptually similar to using the DOM (manipulating objects like adding buttons, responding to events, reading data from input boxes on events,etc) and there is always relatively lot of work with shipping data in and out of the UI objects (either keep data synchronized between UI and internal model or reading data from the UI continually).
Compared to your game rendering code that usually just needs to iterate internal data this always felt like a lot of manual work to keep UI and internal data in sync.
Considering for example a 3D program where you can drag around an object with some arrows, while those arrows are dragged an input-box is updated with the new values and if you want to align the position you might edit the value manually in the input box and have the 3D view show the new position as you edit it. On top of these 2 sources of value changes you might have an animation system wanting that might change these values while animating (so that they are visible to the user), this kinda stuff is usually a buggy nightmare to maintain once you have it in a few many places.
This is why I like Vue and React (Angular.JS also had this to a degree even if it's implementation was weaker than Vue), with both of them you only need to concern yourself with how your internal data works/looks and operations are simple to do since they only operate on that internal data.
Then the Vue templates (or your React rendering functions) takes care of visualizing it with the associated automatic functionality to adjust the internal values if changed by the user.
Sure, if you attach behavior code to every interactive element directly, all of which are controlling the same portion of the screen and depending on each other, it's a recipe for a mess.
If, however, you call somewhat generalized functions on those events, with basic DRY strategies in mind, it's all very clear and manageable well into the thousands of lines, with no need of running a gaming engine in JS, creating a templating language that must be transpiled, etc.
edit: >less manual code
jQuery code if often smaller and clearer, I mean check this classic:
jQuery: https://github.com/tastejs/todomvc/blob/gh-pages/examples/jq...
React: https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re...
Prototype was a great initiative, but I think the community was right when it decided to go the jQuery route, and not append new functions to the prototype. Even though prototype never really caught on, working with websites where it was used partially, or scraping data on websites that used it, has caused me plenty of issues over the years.
You left out 2 frameworks that are important in answering your question, and those are YUI, and jQuery UI. And both of them attempted to answer the same issue. The issue was thus:
In jQuery's hayday, developers wrote code by appending jQuery scripts to events. If you click this button, then the code in $(yourButton).click(function(){}) would run. But at the time, writing OOP, or even well moduled code in javascript was extremely difficult to do, as very few developers invested time into setting up a module system via CommonJS, or AMD modules, with requireJS or Browserify or etc, and almost never did so by default with a normal jQuery page.
The end result is that once your average webpage hit a certain level of complexity, the page itself would have thousands and thousands of lines of JS, each one written as a completely standalone script, triggered off of some jQuery event on the page.
And this is just fundamentally not a good way to program. In what other world would we write code, and say that our architecture is that each user action can trigger a stand-alone script, and that's good enough? Except for JS it was worse, because without a moduling system, there were often conflicts and soft dependencies everywhere between said scripts. Above a certain complexity level, refactoring code from this timeperiod is a complete and utter nightmare. It doesn't help that the inability to program using cleaner architectures resulted in many programmers writing off JS as a "toy" and not a real language, whereupon many of these programmers would then go on to write "toy" level quality of code.
jQuery UI, and YUI both attempted to solve this problem by building a component based approach to organizing your events. Basically enforcing a very simple OOP framework in a world where writing AMD or CommonJS modules was a pain in the neck.
They're both okay. At my company there's still old code from before and after these frameworks came out, and among pages that have thousands of lines of JS, the pages that use these frameworks are miles and miles easier to refactor than the ones that just rely on pure jQuery. We usually take to just completely burning and replacing the pre-Yui/pre-jQuery UI pages, but the Y/jUI pages we can usually refactor or actually debug.
Backbone.js took the lessons learned in YUI and jQuery UI and wrote the first real framework that was any good at building a modern UI architecture that worked in the browser. I could go to a dev who was building a WPF app in MVVM, and explain backbone.js in a few minutes, and they got it. It wasn't perfect, but it was far better than what we had before.
Node.JS standardized how to actually write functional or OOP code in JS.
Angular and React took the lessons learned and failed by backbone, and added in the fact that with the advent of Node, people actually started writing JS as a first-level language.
Angular was an iteration on the problems attempted to be solved by yUI and jQuery widgets. That's to say, Angular's entire approach was to build a heavily boiler-plated framework so that individual developers could write UI scripts in relative isolation from each other, in a very easy to debug manner. It is and was basically what every large development project manager / team lead has been asking for since the early 2000s for JS development. A framework that is so boilerplate heavy, opinionated, and hand-holdy that it becomes easy to debug and review the majority of the code written by your junior JS devs. Its no wonder it was the first framework to heavily enforce static typing and typescript, or that it was pushed by Google. Though Angular has iterated many times over the years, its initial versions were explicitly written with the intent to be used by project managers writing JS who weren't programmers, and to me, it often feels like it is inspired by enterprise JAVA type decision making. You can use Angular for anything, but to me where it really, truly shines is if you have a webpage with a well defined layout, need specific parts of that page to have heavy but isolated user interaction, and your team is not a JS-first shop. This isn't the only place where Angular shines, but my god does it shine in that particular combination.
React took the opposite approach. It also iterated on the successes and failures of backbone. But it attempted to do so with an approach that provided the bare minimum for front end developers to write modern web apps, and give developers an opt-in approach to included what parts of the library they would like to use, and make it easy for developers to write their own packages to be used with the library. Where angular attempted to provide its own core libraries (and correct way to use them) for every possible need a developer could have when building a web page, react trusted the community to develop JS on its own.
Vue, mithril, etc all iterate on react's decisions.
>But at the time, writing OOP, or even well moduled code in javascript was extremely difficult to do
JavaScript is still the same, you still can and pollute the global window object, use global variables, etc.
It seems these frameworks are mostly about enforcing a code style, best practices when dealing with large teams with very different experience levels. Since I work mostly alone and clients don't care what tech stack I choose, I guess I'm in luck.
I'm an embedded guy (very little idea about webdev stuff). Nice summary :)
Both, perhaps (ie. fork it)?
UI wise i need to add an envelope editor instead of entering numbers manually, the player code already has support for envelopes although it needs a bit fixing with how sustain is handled.
Would be fun to "put up" the project for public consumption, took the opportunity to try out a serverless backend (since this isn't something i plan to manage myself or think will pull or cost in any real money) and that was fairly easy for what i have in mind (adding the possibility to share tunes and some 3rd party login for saving stuff maybe)
I looked at the jQuery example above and checked the Vue example in the same repo. That example has about as many lines total but the Vue example is 30% smaller in total due to shorter lines.
https://github.com/tastejs/todomvc/tree/gh-pages/examples/vu...
If you are writing in a modern framework, this is now not possible, without really, intentionally, breaking a lot of things to be able to do so.
> It seems these frameworks are mostly about enforcing a code style, best practices when dealing with large teams with very different experience levels.
Its more like finally having a real programming language, but for backwards compatibility, you can still peer under your framework and libraries and see all the nonsense that used to be available.
> Since I work mostly alone and clients don't care what tech stack I choose, I guess I'm in luck.
Most likely if you're a single person working on such projects, you usually won't hit the complexity needed to justify these tools. That said, since most modern work is being done within them, you are also missing out on the ability to leverage those capabilities when needed. But fair enough!