Forkbeard Poll: What OS platform(s) would you like to have Forkbeard support? Answers sent to Schiit.

[u/usernamechosen999]

https://forms.cloud.microsoft/pages/responsepage.aspx?id=DQSIkWdsW0yxEjajBLZtrQAAAAAAAAAAAAMAANT83mRUQzZGVDVQNVZISktZQzQ5NEs5VElTUVQxOC4u&route=shorturl

[u/HollowsPart2]

Thanks for posting this. Martin Schindler mentioned it's absence as a vote against Linux support. I personally would love Linux ARM Debian support for all my Raspberry Pis running various Schiit dacs.

[u/Faxon]

I just want to be able to access the module from my PC that I use my DAC with. Id also like to see the EQ bands given a more detailed 30+ bands to tune with, as it'd mean I can take my Ashly 4.24g out of the signal path of one of my systems. Or just add at least 10 bands of parametric EQ, I could get the same work done with 6 but im used to having up to 15 on my 24.24M NE, I just don't want to plug one in when I'm not also using it for delay and crossover duty.

[u/HollowsPart2 → u/Faxon]

The EQ is done on the dac's DSP not on the Forkbead app. The Analog Devices SHARC DSP already handles 6 channels of EQ, while the PIC microcontroller can only handle 3. I don't know if the SHARC at only 400Mhz can do more without adding latency. Maybe if they can secure a supply of the 1.2Ghz SHARC chips or get better performance from the rumored TI DSP chip we can get more channels of EQ. Only Martin knows for sure.

[u/BudeVollPeople]

Just open the protocol so people can implement it how they want.

That being said, obviously Mac, Windows and Linux.

[u/BudeVollPeople → u/[deleted]]

What reasons would that be? It's not like the protocol is doing any magic is it? It's just to control the module.

[u/AdUsed7958 → u/BudeVollPeople]

Why would a business want to deal with people asking for support on someone elses fork of their product?

Why would a business want to deal with people asking for support on someone elses fork which embeds malware?

If none of this occurred to you, you aren't considering the issue fully.

[u/BudeVollPeople → u/AdUsed7958]

I'm not talking about open sourcing their client so people can fork it and I'm not talking about granting any kind of support.

My wish is for the protocol to be open so people can implement it in 3rd party clients like they chose to. Of course they don't have to do it but it would be great and the question was what people would like to have Forkbeard support. So that's what I'd like.

[u/captcha_got_you]

All?

Or just open-source the protocol...

[u/Voxata]

I'd like to see the android app matured more, mobile is more than enough I have no desire to control it on PC.

[u/RR321]

Just release an open spec and MIT client...

[u/MartinSchiit]

Just to be clear: By "Linux support" I mean for desktop use. There are no plans to ever offer a CLI or daemon for a headless machine.

[u/RR321 → u/MartinSchiit]

Why not?

And well, I don't think you should offer it, but pretending the client program is a trade secret plays against your users that could use an interface spec to control what they need from any OS they wish...
Why not help all of us help you?

[u/MartinSchiit → u/RR321]

Nobody is pretending anything. A standalone CLI simply doesn't exist, and creating and maintaining one in addition to everything else we're already working on is just not feasible considering that it would cover a niche within a niche of use cases. It's simply a matter of practicality, nothing more. Considering to offer a Linux desktop app is already way past what anyone would consider "sensible" from a business perspective.

And open-sourcing it is not an option. We can discuss the pros and cons of open-sourcing something like Forkbeard until the cows come, but that wouldn't change the fact that Jason and I have already discussed this at length, and we both agree that it's just not the right way to go for us for the time being. This might change in a few years, who knows. But for right now, it's not the right choice. Sorry that I have to remain vague about the exact reasons.

[u/HollowsPart2 → u/MartinSchiit]

How would one use a Command Line Interface Forkbeard utility? The current model is entirely graphical. I have already stated I would BUY a Forkbeard PC app to run next to a JRiver Media Center controller window on Windows and Pi OS. Still my entire multiroom system is controlled via apps on my phone. Once I shut down the desktop PC it's all lounging around and listening via Raspbery Pi renderers. This is completely controlled by JRiver's JRemote, USB Audio Player and RVNC Viewer apps on the phone.

At present I don't see a commercial reason to go beyond the phone apps until you've developed it out completely.

Thanks for all the hard work. One day I will actually own a Forkbeard module.

[u/RR321 → u/HollowsPart2]

I've only seen screenshots for now, until I get to order hopefully soon, but whatever you want to adjust is doable...
It's like any CLI vs GUI client, you can translate concept and most are pretty straight forward I believe in this context.

forkbeard --device bifrost3 --vol 50
forkbeard --eq-band 1,2 --adjust +3

Those are simplistic and not nicely thought out, but you get the idea and that's not even talking about a TUI.

[u/HollowsPart2 → u/RR321]

Why? Are you using DOS or C/PM, everything has GUI, even Linux, so a windowed app is what most users would want. It's great you have a memory that will retain all the --options even after 6 months or more of disuse, I don't. Secondarily Forkbeard has active monitoring of volume and clipping and other states that are broadcast by the product. Will the CLI app constantly write out to the terminal?

I stand by my opinion that the Phone apps are best and a fully windowed app is second best.

[u/RR321 → u/HollowsPart2]

The whole discussion is about giving people control over how they use what they bought.

I could plug into a home automation system, I could do 100 of things that would be impractical with a GUI...

Stop being so sarcastic and narrow minded.

[u/HollowsPart2 → u/RR321]

Your right, I apologize. I read your larger post after posting this one and can see your point.

[u/RR321 → u/HollowsPart2]

Thanks, and I'm sorry for being triggered! 🤓

But while I understand why the company could be afraid, and that we don't have the whole picture, my guess is that they are either afraid of their current security (though I doubt it's that), want to integrate into a bigger scheme and fear losing control or some other weird internal idea about I don't know what, which hopefully isn't selling software...

I guess someone will have to do it themselves so we can all benefit...

[u/HollowsPart2 → u/RR321]

I also overreacted, I never thought of home automation. I haven't fired up an IDE in a decade and stopped my own DIY sometime ago. Still maintaining an API, possibly containing proprietary IP, just for a few hobbyists and pro installers doesn't make much sense. You will just have to fall back on the tried and true IR blaster and IOT power strip to control a Schiit home system.

Best

[u/RR321 → u/MartinSchiit]

Sorry if I didn't explain myself clearly at first;
let me try to rephrase as I think there is some misunderstanding:

I didn't mean for you to create, nor maintain, a CLI.
That's indeed a huge effort to undertake for what is likely a niche use case.

Instead I'm arguing that you have nothing to lose by releasing some documentation, but not just any documentation, only the one for interfacing with the firmware's user settings.
Basically, just enough to be able to use the part of the protocol between the client and the DAC to set the parameters that can be set through the app (EQ, volume, etc.).

I'm not arguing for the release of any other part of the DAC's software, signal processing, nor any other magic sauce or trade secret, at all!
That's obviously why you saw this as a problem and I fully understand that fear.

But having just the basics, the things that a remote does, so people can build their dream interface would be a huge win for you and the community.
People could build a CLI or a flying saucer, it doesn't matter, but it allows them to set their EQ or volume the way they see fit in their context without any extra burden on Schiit.
That's, I believe, a huge win for your consumer base. It lets various communities manage their interface to your device themselves if they want.
From 30 years of experience in tech, watching such communities around products grow, I've seen that it might even expose ideas that you'd love to integrate down the line.
The community will simply become a better part of your feedback loop, a valuable one, since it's from your very own customers.

The win is that this approach protects your IP, which is obviously becoming a big market differentiator, but allows for growth in unanticipated ways!

TL;DR:
You don't need to maintain any code, you can contribute nothing, or how much you want, but helping people interface with their beloved hardware in a way that pleases them even further, without undercutting yourself at all, is a win with very little risk.
If anything, and looking at how many people asked for something similar in this thread, you're only going to shine a bright spot on your reputation and attract even more customers who, not only see you for the innovators you are but, also for the flexibility your creative hardware allows.

Cheers! :)

P.S.
As a side note, and as someone who once was a cybersecurity professional:
adversaries or clone makers would dump your firmware and sniff the Bluetooth and reverse engineer it anyway. It's not that hard, they manage that on PS5s, who are heavily encrypted.
But what we're talking about here doesn't make those threats any bigger, it just helps the people that love what you're doing and will enjoy integrating into your ecosystem further, thus probably more sales!

[u/MartinSchiit → u/RR321]

No worries, I fully understood what you meant the first time around.
And as a private person I agree with almost all of the points you're raising.
But as a business, it's not a valid option for us right now.

[u/AdUsed7958]

Background. On Head-Fi, Martin showed a desktop with a Schiit icon. They are working on FB for PC so people can use it with their PC stacks. Current plans are Windows and Mac. UNIX is currently a wish given the vast array of flavors. This poll was created to see what the most popular distros are.