dmoreno

I was just listening to the midi 2.0 webminar from the midi association, and as I understood there are some free sysex and ci id for non profits / hobbists, but if you make money out of it you should register. I guess mainly to prevent ID collisions.

Music performance is a synchronized effort, and with very precise timings. If there is lag, everything is just a bit late and a musician can (unconsciously) compensate up to some point. But for example (if my math is correct) 120 bpm, has 8th notes every 250ms.

If drum beat is sometimes, and only sometimes, 100ms later than it should, the result is not nice at all. And it is random jitter.

I for one expect that MIDI 2.0 helps to boost the RTP MIDI protocol adoption (over ethernet). It has much more speed, longer distances, less latency, proper packet loss recovery (which is not a problem on local networks) and overall much better hardware ecosystem.

Even on WiFi it is useful although latency is very jittery.

Disclaimer: I'm working on a RTP MIDI implementation for linux (https://github.com/davidmoreno/rtpmidid)

As I read it, in brief, it adds much more resolution, and a introspection protocol using bidirectional communication which allows property exchange and profiles.

Both very welcome additions! Finally no stepping on CC and note velocity, and the DAW can really know about the synth / controller capabilities, as it knows already with VSTs.

And keeps MIDI 1.0 compatibility.

It does not make sense to use it in games. It would need a good synthesis engine plus samples which consumes much more CPU than reproducing a MP3.

If in your game you go the synthesis mode (chiptunes and whatnot) MIDI is a comunication protocol between devices.. if you want to use it to communicate a game with its own synthesis engine it makes less sense. Buy you may want MIDI so you compose in a standard music composing program.

It is used also in other areas that need automation, as lighting (DMX).

But I agree it would be nice to have better examples.

As explained by LWN: https://lwn.net/Articles/776703/

This sentence, when talking about support for old enterprise versions, is a bit suspicious:

> Satellite will not use newer versions of MongoDB that are licensed under SSPL.

So my read is that there is not only an intention of database consolidation, but also a desire of avoiding the SSPL.

I loved the AOSA books, but there's been sometime that they don't publish a new one.

Do anybody know if there is something new in the works?

And of any other similar books?

Email has several retries. Something like 6hr, 1day, 2days... After that the sender receives a delivery error.

All that is managed by the SMTP servers and the numbers change, but normally just losing internet connection or power for some hours doesnt make emails dissapear. By design.

> This suggested techniques to eliminate loads and stores (e.g. switching to a register based bytecode) would be an effective optimization.

Did anybody try anything in these line of work?

I still have to read it through, but why does it require new syntax and not just new standard library additions like boost::coroutine?

I just fell in love with boost::fiber so i hope there will be also something like it in the future std.

License.

Electron is MIT. Ultralight is proprietary. Electron always free to use even on comercial, ultralight only for small projects.

Another alternative is nextcloud... It also has a sync desktop client and works great in my company for sharing folders with colleagues or keep business documents in sync on desktop and laptop.

There are even third parties that install it and manage it for you.

[1] https://nextcloud.com/

Now it needs a --output=json option to make it awesome and usable from scripts and programs.

AKA calendar versioning. I also love it.

http://calver.org/.

Anybody knows if this also can help improve performance of language interpreters such as CPython?

Similar, but as a library, I did ExoSQL, for elixir [1], and heavily inspired by FDW from poatgres. I think there is great potencial on mixing data from many sources!

I think exosql has more features (lateral joins, subqueries, JSON support...), but I'm super happy to see more players in this field.

[1] https://GitHub.com/Serverboards/exosql

From the article:

"For performance, it runs with .NET Core on Windows, macOS and Linux, works with Python 2.5 through to Python 3.7 and supports the latest language features"

I completely disagree.

Unless your data requirements are very specific, mem only, or not adapted to the relational paradigm any SQL engine will provide you with the best and more efficient algorithms to manipulate your data in the most common situations.

I think that if any, databases should be used more.

I followed specially the postgres and sqlite documentations. For some specific areas I checked their source codes. But mainly I used explain from postgres as reference on what algorithms (seq scan, hash scan and do on) use for specific queries.

I recently created a database engine (exosql [1]), only query and no storage. It uses postgres-like foreign data wrappers to get all data.

It's not valid for big datasets, as it stores all in memory (or maybe it is?), but as a learning experience has been amazing to think and develop a real database: planner, executor, choose algorithms, implement features as lateral joins and so on.

I will definetly listen very carefully to these talks.

[1] https://gitHub.com/Serverboards/exosql

My bet is in highly distributed and parallel programming languages as Erlang, elixir, pony... As computers get more cores, these process/actor oriented languages have an edge. And they provide transparent distributed computing.

Good enough as Go (not distributed by default) are indeed worth watching.

After thought languages as java/Akka, c++... They will be there for sure, but will not give any edge.

For me it's also a deal breaker, but I will keep an eye on it.

Multiple database vendor support, not only postgres.

Sure, why not?

If it spreads the idea that there are several ways to do versioning, and not only semver, and it gives a proper rationale, I'm ok with that. (server.org might be difficult to register though).

CalVer is just a pattern with a name so you can talk around about why Ubuntu uses year.month as version, and some ideas on when it is good to use it or not.

Serverboards developer here.

They have in common that both show dashboards, but the strategy is different.

Serverboards focuses on the USQ and SQL to show the data from external services, using third party independent plugins using json-rpc to communicate. Graphana on the other hand also allows to develop plugins to show and extract data, but using their custom protocols. In brief quite similar, different approach.

But Serverboards also allows to create custom screens (react or your own way) and backend plugins (any language, but python best supported) so you can extend what Serverboards can do. For example there is a basic cloud management plugin.

Check https://serverboards.io/developers/ as a starting point on what's possible to do.

Thanks for the hint. Fixed!

So it is like React but for server management, and using it's own functional reactive language [1].

That's super cool! I definetly will keep an eye on it.

I would have preferred a more standard language, but I guess it's difficult given the problem space. Actually looks easier to understand than force feeding yaml into ansible.

[1] https://en.m.wikipedia.org/wiki/Functional_reactive_programm...

I loved the heisenbug/bohrbug distinction in the zen of Erlang [1]:

> Basically, a bohrbug is a bug that is solid, observable, and easily repeatable. They tend to be fairly simple to reason about. Heisenbugs by contrast, have unreliable behaviour that manifests itself under certain conditions...

It continues talking that for some kind of heisenbugs, one smart strategy is just to restart to a known state, and forget about this one in a million failures (let it crash).

[1] https://ferd.ca/the-zen-of-erlang.html

With a system based on plugins and components like Serverboards[1] its quite easy to create new functional areas (screens[2] in Serverboards parlance) as the ones you describe. Some times its more difficult to really round up the ideas to make something useful, than implementing it [2].

If you have specific ideas on how would you like a functionality like that to be, I'm all ears to make it real!

[1] https://github.com/serverboards/serverboards/ [2] https://serverboards.io/developers/18.01/plugins/screen-defi...