Hacker Newsnew | past | comments | ask | show | jobs | submit | brudgers's commentslogin

AI comments are not in the spirt of and the account is basically about as in the spirit of HN as it gets.

You'd pay $10-20/month if something just worked

If you are selling to ‘enterprise’ that business model might work well as a per-seat price.

At retail, into small bespoke niches a business built on $20 problems is unlikely to be sustainable because it is not enough money to reliably reach small markets and it is not enough money to sustain high quality service to a small number of customers…sure 1000 customers would be $20,000/month, but you have to get there first and stay there second.

Getting there is probably more money and calendar pages than you think and staying is going to gobble up more of the $20,000/month than you want through churn and employees.

My advice: find some thing you want to work on or find actual customers who will pay you handsomely to solve their important problems. Good luck.


Just a guess:

building an amplifier from transistors is sometimes simpler/cheaper than using an op amp. And some designs don’t need the benefit of op amps.

On the other hand, building a timing circuit from discrete components is less obvious. And the 555 does so much of what often needs doing.

Also, the design was not patented so they were commodity chips right away.


https://www.swift.org/documentation/articles/zero-to-swift-e...

You could probably use Emacs for Swift...just like for about every other language.

Whether you still must download a monstrosity is left as an exercise for the reader.


I'm using flutter and had to download xcode to build the app so I guess it's a necessary step.

I'm using flutter too, I've found a website called codemagic, so I can make builds for iOS. My laptop is windows. The bulk of development is building for Android.

I repeated my above concerns and he said that they hired me to do tickets and that was it.

It sounds like doing tickets is what needs doing.

And “you’re doing it wrong” ain’t doing what needs doing.

How you handle that will determine how you grow as an engineer.

How you behave will determine whether people want to work with you again.

My advice: roll up your sleeves, spit on your hands, and grab an ax.

The pile of wood ain’t gonna chop itself.

Good luck.


For what it is worth, Microsoft is in the process of rolling out Windows Midi Services for Windows 11.

https://microsoft.github.io/MIDI/


Why on earth is the "Windows MIDI Services is Here" thing a slider/carousel with one element in it? Why are the buttons completely misplaced with no margin between them? Has a human seen and tried this before they just deployed everything and went live?

Why so mean? You can look at all of the commits and see that the same dev who has been writing these drivers and apps pretty much single handedly has been making commits on the site for the past few years. https://github.com/microsoft/MIDI/commits/main/docs

You can even PR fixes if you want to show off your web dev skills.


+1 to this. Psychlist1972 / Pete is good people.

Pete is one of those rare Microsoft developers who is actively interacting with customers publicly. He's active on the Gearspace forums where musicians hang out, helping people with their Windows issues relating to operating system level audio issues. Here's his Gearspace thread announcing the new Windows 11 MIDI drivers:

https://gearspace.com/board/new-product-alert-2-older-thread...

I wish there were more people like Pete working at Microsoft. He's someone who is genuinely trying to improve the OS and make it a great experience for users.

EDIT: Re-read the original post and I see Pete even checked this project out and commented on Reddit. Sorry I missed that the first time.


Most choices are not between bread and cake.

Most choices are between bread and nothing.

Good engineering is the art of good enough.

Outrage is hardly warranted.


> Good engineering is the art of good enough.

Sure, agree. When will this website reach the state of "good enough"?

> Outrage is hardly warranted.

Agreed, but I also don't see any outrage in any of the comments for this submission, what outrage are you talking about?


It's good enough if it conveys the information to its intended audience.

If the comment isn't outrage, it's even less warranted.


Valid questions even if all of them are rhetorical.

Because slopsoft.

A few more years and we might be able to approach Atari ST levels of MIDI performance…

Never gonna happen. The architecture of modern hardware and operating systems won't allow for that kind of low latency and jitter.

Specifically for Windows, the Intel 2001 Guidelines and Microsoft WHQL (Windows Hardware Quality Labs) which prohibit the use of MPU401-style interfaces, as well as direct driver access to either the serial or parallel ports.

Doing Direct-To-Bus MIDI handling can't be replicated in modern architecture like the ST was configured.

That said, given the popularity in analog semi-modulars to be used as DAW outboard with MIDI over USB implementations that add latency and jitter, is it even a consideration for most users?

Ableton and other performance oriented DAWs automatically compensate for MIDI and audio latency caused by plugins and devices; in Ableton's case it will delay the audio by the overall system latency, and/or bypasses plugin delay compensation only for armed/monitored tracks, making them more responsive.

The real answer to the question is, as always, to use hardware sequencers and control voltage triggered off your master clock or DAW. SQ-64 is as rock solid as an Atari ST for CV work, although the 64ppqn limit doesn't match the Atari ST' 384pqqn capabilities. That said, standard MIDI Beat Clock is much lower at 24 PPQN. If you want to go all Autechre/Aphex Twin there's plenty of ways to skin that cat.


If you care about timing over Midi, use MTC not Midi Clock. Because receivers have to derive clock frequency by counting pulses, Midi clock is inherently unstable.

Midi Time Code is SMPTE.


MIDI clock on the Atari ST was rock solid. It being "inherently unstable" is one of those accidental things, like Windows 9x users assuming "computers just crash all the time".

No matter how solid the source of Midi clock, the receiver has to interpolate it’s own clock from multiple midi clock messages. Those messages arrive after passing through a network with arbitrary reliability, latency, and jitter.

The instability is at the protocol level. That is why Midi timecode exists.


Fun, I do the opposite, explicitly use Midi Clock so everything is purposefully a tiny bit out of sync, seems to sound better to me, "Midi clock is inherently unstable" is the feature I like :)

There are technologies like MTS (MIDI timestamping), where you basically send timestamped data early to the interface so that it can then play them out exactly (or more exactly) at the right time. This was initially made by MOTU but I think the implementation in Core MIDI is based on it.

Emagic and Steinberg also implementation of this (AMT in case of Emagic, LTB for Steinberg IIRC.

This only really works with recorded data of course. It's also very old already (like 25 years old), I'm not sure how well it is still supported in current DAWs.

With these technologies, timing should be as good or better as on an Atari.


Multi-client support? I must be dreaming!

The biology article led me to submit this. No coincidence.

Logically that the burrito metaphor can explain monads, implies that the burrito metaphor can explain biology.


Co-ops primarily are a way of funding local infrastructure that serves small businesses and communities when there is not a viable ROI for commercial banks or existing businesses: for example grain elevators, rural electrical service, grocery stores etc.

“Tech” (whatever that is) probably tends not to have cooperatives because it does not have a similar combination of conditions.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: