dmoreno

Just cancelled my subscription.

I've been using the Pi agent with Deepseek for some days.. and I'm more than happy with that.

Just vibe coded a calendar based group meeting app. A group of friends create a calendar and share the link, can coordinate in the chat, and in a calendar choose the day and time to meet. Everybody votes and that's it. All this in a nice brutalist web design. And no registering needed.

https://meetday.net/

When they say "The episode occurred when threat actors gained access to this third party legacy system which was not decommissioned properly. " for me it sounds like a not properly wiped disk that got into the the bad guys hands. It would be interesting to know more to be prepared for proper decommissioning of hardware.

A cpp code generator like esphome, to generate the firmware for midi devices in a simple yaml file, for raspberry Pico.

It would have been so much easy just to program the midi hub I wanted to program but wanted to make it generic.. now I can make the firmware for any configuration in seconds!

If I were them I would make sure the V3 instructions are not used until late in the boot process, and some apt command that makes sure all installed programs are in the right subarchitecture for the running system, reinstalling as necessary.

But that does not sound like a simple for non technical users solution.

Anyway, non technical users using an installation on another lower computer? That sounds weird.

I use home assistant and a smart plug to get notifications when the socket has less than 1w load for 5 mins -> washing machine finished. Maybe one of the best automations I have. And all local.

Happened to me last week. One morning we wake up and the whole company website does not work.

Not advice with some time to fix any possible problem, just blocked.

We gave very bad image to our clients and users, and had to give explanations of a false positive from google detection.

The culprit, according to google search console, was a double redirect on our web email domain (/ -> inbox -> login).

After just moving the webmail to another domain, removing one of the redirections just in case, and asking politely 4 times to be unblocked.. took about 12 hours. And no real recourse, feedback or anything about when its gonna be solved. And no responsibility.

The worse is the feeling of not in control of your own business, and depending on a third party which is not related at all with us, which made a huge mistake, to let out clients use our platform.

Anybody know if there is some effort for an open source firmware? It would be so cool to have a watch like that with the pinetime firmware...

rtpmidid[1]. After getting some hardware synthesizers and wanting to connect them without using a computer.. but being able to use them too using the computer I stumbled upon with rtpmidi the protocol and it ticked all the boxes I needed. I could connect all my gear to a raspberry pi, use ALSA sequencer to connect devices to each other with another of my programs AseqRC[2], and then use my synths from my DAW without touching any cable.

So after a fast prototype I created rtpmidid and I'm quite happy on how it works.

And it also helps with the USB ground loop noise that it seems unavoidable some times.

For some time I had even two Orange Pis connected to two sections of my gear, using USB gadget support so my MPC One could speak rtpmidi. MPC One has support to connect as host to MIDI devices, but as guest (connect to the computer) only in controlled mode which is not what I needed to convert my MIDI tracks to my DAW.

[1] https://github.com/davidmoreno/rtpmidid [2] https://github.com/davidmoreno/aseqrc

I am also very bothered by this. I developed rtpmidid just to be able to use rtpmidi on bitwig.. and I need to use the virtual midi device hack.

I was just thinking if there is a way to ask for features.. and there is! https://bitwish.top/c/features/5

I will add the request for ALSA sequencer devices, which I think should include Jack ones.. but I will investigate this further, as maybe I'm wrong. There is a bridge for sure.

Anyway just don't hijack the MIDI device and be nicer with the linux MIDI ecosystem is a must.

Just donated 15€! Thanks Kicad team!

My favorite is more a small presentation than an image: Admiral Grace Hoper Explains a Nanosecond. https://www.youtube.com/watch?v=9eyFDBPk4Yw

For me it changed my mind on wasting time on less efficient algorithms.

Any widely used disk format still uses 32-bit epoch?

Somehow I thought of FAT.. but UNIX epoch does not make so much sense...

And don't forget distcc [1], together they can speed up compilations and recompilations. I remember using colleague computers to speed up a 30 min C++ compilation to just 5 min... to just seconds on second compilation.

[1] https://www.distcc.org/

For reference, as I didn't know, posits are a modern float number alternative to IEEE 754. Wikipedia[1] claims better in many aspects, but, as ubiquitous as IEEE numbers are I don't see them getting replaced soon.

[1] https://en.m.wikipedia.org/wiki/Unum_(number_format)#Unum_II...

IANAL, but as far as I know it's very important it's GPLv3 which means the antitivoization clause, which means that hardware that uses this firmware must provide full source code and a way to let you use your own firmware.

If somehow this code is not in a firmware... No idea.

My hope is that they finish the MIDI 2.0 rtpmidi protocol, and that starts to be truly used in real hardware, not half used as current rtpmidi.

This would allow easy connectivity with very low latency over normal LAN, including switches, power over Ethernet...

Disclaimer: I created a rtpmidi implementation for linux https://github.com/davidmoreno/rtpmidid

Not exactly what you are looking for, but I created a web interface for ALSA sequencer, which effectively makes any raspberry pi what you are looking for.

For old MIDI DIN you would need a MIDI adapter or use the raspberry pi serial ports and some circuitry. Can be powered by an USB powerbank for example.

https://github.com/davidmoreno/aseqrc

I also added to the mix rtpmidi (https://github.com/davidmoreno/rtpmidid), and USB MIDI gadget (https://github.com/davidmoreno/midiconfigfs) on the PI, so then I can use the pi itself from one or several computers via Ethernet and USB.

I loved how it had precise examples of bit flipping because of cosmic rays, and its consecuences.

Not scientifically accurate, but Google trends gives a hint. And absolutely not dying, but react keeps growing at angular's expense.

https://trends.google.com/trends/explore?date=today%205-y&q=...

The title says "extensible in Guile" which sounds great, but I don't see any mention in the article.

Is there any resource about this Guile extensibility?

It would be very unfortunate if free software users would have to remain vulnerable for a full year before they could have access to a newer version with a fix.

The last published version, even if its 12 months old, is and will be open source and free software, so it's up to the users and developers to keep it security updated. As with all free software. Is not as if Qt does not fix it nobody will. This is not closed software.

It has a mechanism to reduce it, quite probably adding some latency. But better always 8ms of latency than random jitter between 1ms to 8ms.

This will also help with WiFi + rtpmidi and bluetooth.

From the (oldish) midi.org article[1]:

The Universal MIDI Packet format adds a Jitter Reduction Timestamp mechanism. A Timestamp can be prepended to any MIDI 1.0 Protocol message or MIDI 2.0 Protocol message for improved timing accuracy.

1: https://www.midi.org/articles-old/details-about-midi-2-0-mid...

I have not checked the docs yet, but from what I read so far the protocol is actually easier, with clearer fixed size messages for usual operations, with much more information.

But it is always required MIDI 1.0 compatibility, so if your device need the extra bits, it activate the MIDI 2.0 protocol. IIRC it is possible to use other parts of the MIDI 2.0 as MIDI CI with the old MIDI protocol.

Also things like MPE I think are really improved, as current MPE is an ugly hack using channels. Time wise MIDI 2.0 should be easier to implement than MPE, IMHO.

The most difficult part would be the MIDI CI (Capability Inquiry) to first set up the MIDI 2.0 protocol, and then to send information about current device. But the info about the current device is actually a JSON file, so not really difficult.

MIDI is just the protocol and then there are transports.

One of these is ethernet (RTP midi), which should not have this problems. Or Bluetooth, or WiFi (very bad latency).

Or USB or DIN 5.

Mine watches for changes in a directory and runs a command on any save change. I use it a lot for Test Driven Development. Modify source code, save and automatically on a terminal it runs `make test` or similar.

https://gist.github.com/davidmoreno/c049e922e41aaa94e18955b9...

For RTP MIDI, UDP is used. So anything that can transport UDP.

Simple Ethernet is more than good enough... but of course the lower the latency, the better.

As a side note looks like Adobe has a patent(!) on tabs... And it expires today!

https://patents.google.com/patent/US5546528

I guess you can use the free IDs, and then place the uuid in the stream or packet. Everybody happy.

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.