wdfx

https://www.rmg.co.uk/collections/objects/rmgc-object-79394

Believe it or not this piece was rescued from being scrapped by my father, who had unique interest in both horology and was a professional electronics engineer. This clock was expertly restored on our family dining table at home - including the build of a new solid state power supply for it. I think the museum still powers up this clock for display, and you can watch the large neon decade dividers doing their thing.

EDIT: appears to have been removed from display according to the linked archive page.

I have at least one guitar that I rarely play but I keep because I consider it a work of art and a collectible. But, I have others which are workhorses and I play daily.

It gets awkward when collecting is presented as a way to be a better musician, which is clearly false.

I'm long overdue adding something, work has been keeping me occupied of late.

Compared to the anthropic offering is night and day. Claude gets on with the job and makes me way more productive.

Currently inside is an i7-9600 which I limit to 3.6ghz and a cheap 1050ti.

The CPU is technically over the TDP limit of the case but with the frequency limit in place I never exceed about 70degC and due to my workloads I'm rarely maxing the CPU anyway.

There is zero noise under any load. There is no moving parts inside the case at all, no spinning HDD, no PSU fan, no CPU fan, no GPU fan.

I love it. It's beautifully engineered. Top quality. It sits at the corner of my desk proudly silent.

I'm likely about to upgrade the pc within but the case will remain a strong feature of my desk.

Even this is still a problem, because it's unlikely they know even what question to ask. Or if a sensible question is asked it may be an XY problem, where what is really intended is not what is asked.

Having thought about this for the last few minutes, it does seem inevitable that the software would have to start coaching the musician in the ways of the engineering and of "music software" people, so that the inputs become more accurate and aligned with the outcomes the software is capable of providing.

I think everyone would crave becoming more productive in the environment over time and not have to suffer the initial baby steps forever.

It's very difficult to imagine a DAW environment which exposes deeper functionality that is not already like a lot of the existing packages.

Edit: and one final thought - it's a hard environment to build by the nature of the work being done being a creative process with no correct answers and which needs to support a multitude of different approaches to creativity. It's pretty opposed to software being generally a machine with a fixed number of functions

If the software was primarily driven by a command list back-end, had a bunch of semi-preset solutions to common problems, and also could be "spoken to" - would that feel more comfortable for our musician user?

Some have developed much further though to support a more digital-first approach.

But it's true that the barrier to entry can still be very high. Trying to explain any of these packages to a musician who is not also a computer power user is extremely challenging, believe me I've tried.

If we could arrive at a point where a DAW can be intuitive to a musician and not technically overwhelming that would be very interesting.

What would be more interesting though would be if that same project could be viewed in an "engineer mode" which exposes the technical view for someone else to work on at a different level.

There's a huge divide between people who might play with this at home as a toy and those who would be able to work with professional musicians with it.

The latter group will have some very strict requirements around performance, latency and workflow.

Edit: and reliability

This is absolutely not true. Latency in audio systems is important in almost every aspect of using a DAW

You cannot be performing to audio that you are hearing with any delay, especially if the monitoring of the live audio is also being routed through software.

At a certain point of latency it introduced delays and badly affects how you perform. In some circumstances it makes performance actually impossible.

There are ways around this, namely if the software knows exactly what the input and output latency is then the playback and recording can be compensated. For live monitoring though you really need that done in the audio hardware itself in hard real time.

I have a history experimenting with 3D audio - about 15 years ago I build myself a pair of ambisonic microphones, but until only recently I think the software support for ambisonic capture and mixing has been seriously lacking. Back when I built the mics I started working on a plugin suite for the processing, but I could never get it quite right. Nowadays, there are more 3rd party options I can use, and I will spend some time with this again :)

I also took that setup to allow me to sync some selected media back from the NAS to my phone.

This way I am not reliant on cloud services as the primary store of my personal data, and I don't have to use their export tools to get my data back. I back up the original sources directly from the phone to my own infrastructure.

In the 90's I recall London area prefix changed from 01 to first 071 (central) and 081 (greater) and then 0171 and 0181. Later still, those codes became 0207 and 0208.

I still notice old shop signs up with the old prefixes.

That's some sweet workflow optimisation. :)

I'd have tons more free time if I just outsource all the little tasks that keep me busy to my significant other.

e.g. https://www.aliexpress.com/item/33010159305.html?spm=a2g0o.p...

It would feel a lot better if it was this, for example, where you use each context explicitly:

  from diagrams import Diagram
  from diagrams.aws.compute import EC2

  with Diagram("Simple Diagram") as d:
      d.add(EC2("web"))

  from diagrams import Diagram
  from diagrams.aws.compute import EC2

  d = Diagram("Simple Diagram")
  d.add(EC2("web"))

For example, at $work we use Confluence for documentation - I just don't see any of the solutions mentioned in this thread as being compatible with deploying diagrams to confluence, or indeed any type of CMS. It seems that at a minimum you need some bespoke docs rendering pipeline in every repository which spits our rendered docs and diagrams to some other platform?

How does everyone else solve this?