329 karma · joined September 25, 2008
You aren’t alone
Bear with us means, ‘I’m about to do a bunch of description… shore up your mental banks and prepare to reread the next bit a few times.
Man
We need to take that section/link down.
We did do a KickStarter for the JamBlaster, made ~200 and shipped them.
https://www.kickstarter.com/projects/1091884999/jamblaster-t...
But we are not in a position to be focusing on custom hardware.
... a dedicated device is half the puzzle. That, and a low-latency network connection to your peers. You have those two and you can get a reliable experience.
We see that too: 25ms one-way latency is the max to stay in sync, and that includes both internet + audio device encode/decode, which gets eaten up quite fast!
We are looking at providing an optional premium networking service to offer a faster connection as an alternative to the open internet. Nothing too expensive, like $10/month is the goal. Hope that gets you and your friends under that magic threshold when it's available, if you try it out.
We do have a tray icon too, though.
So when you browse to our site via the desktop app, certain OS-only features turn on.
So it made a bunch of sense to use QtWebkit. I welcome the switch to QWebEngine though, if for nothing else in the hopes that the underlying browser code gets a update and the app will hopefully then feel more responsive.
We had no choice technically-we need to use audio APIs on Win/Mac to get our job done.
Based on my experience, I would not recommend building a desktop app unless there is a technical reason to do so.
Data storage, building installers, signing your app for target OS's, and dealing with auto-update are all technical problems that I'd prefer to avoid if I could. Building cross-platform code is also a pain and, while totally doable, will slow down a team that is not familiar with it, I think.
If I really needed to build a desktop app in the future, I'd investigate building building a headless app that hosts a websocket, and use the user's browser to connect to a localhost websocket to communicate with it. (i.e., a technical choice freeing my from Qt)
My back has hurt for about 15 years, since the age of 18.
I didn't exercise reguraly during that time.
I haven't had any pain for the past 2 years... The change us definitely tied to this: I started working out reguraly (HIIT style in my case).
branch-buildno
Where branch is the git branch, and buildno came from our build machine (Jenkins in our case).
examples:
* develop-5
* master-10
I then used this ivy-based project: https://github.com/sethcall/depends to push those dependencies to our own internal artifact repository.
Because of this, I could say, 'use the latest artifact on the develop branch', or, I could say 'use exactly master-103'. Those two alone were pretty powerful.
By the way, I asked Maven devs if this would numbering scheme would possible (at the time, I would have happily used Maven instead of Ivy because I had to build some tooling to use Ivy); they were strongly against the idea: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-curre...
https://github.com/TannerRogalsky/sprockets-es6
Rails is still a second-class JS citizen due to the asset pipeline being opinionated and controlling compared to the node way of doing things, but it gets you closer to 'the new hotness'.
Perhaps because I never had to switch out to a browser (usually I could just 'tab' to the right answer), I was able to keep the code in front of my eyes and 'loaded', and somehow etch more corner-case syntax into my brain.
We use a 'monorepo', so everytime we update any gem dependency, all of our apps get rebuilt entirely. So, updating all of our packages or not isn't a problem.
And I like the duplication, believe it or not. After having debugged environmental problems with dependencies in various languages over the years, I'm happiest knowing the dependencies in question are in vendor/bundle; end of story. Sometimes, in case of a nasty bug, I have a one-liner fix and I can go to vender/bundle, tweak the gem, and know I only affected the app using it. Those are things I prefer over some lost hard drive space.
Build times are a little long for us, though. That is true. I do a fresh bundle install on every build. That is the second longest part of the build, behind running our dog slow web tests.
We take all gems associated with the app (like a Rails app, but we do it with others), and stuff them along with the code into a package created by fpm.
In other words, the packages are completely self-contained; no gems are used from the environment.
The key to this is the --path option to bundle install, i.e.:
bundle install --path vendor/bundle
This command makes sure all my gems are in a sub directory of my project called vendor/bundle. When creating the debian package using fpm which includes all the source code, vendor/bundle also comes along with the package.
After installing the app on our Linux servers, 'bundle exec rails server' uses the gems from vendor/bundle.
This approach does require that I create the debian package on a machine that closely mirrors the deployed servers, so that compiled gems make any sense.
Most all the issues described in the article have not been problems because of this approach. I used to use rvm as part of my build process; it was very brittle. I'm completely happy now; just wanted to share in case that helps someone else.
Anecdotally, I know a dentist that would work 2 days a week there as a sort of 'import-a-dentist' program, and she thought teeth were, in general, in much worse shape there than Little Rock, AR (3 hours away). Not enough to go on obviously.
Because latency is an absolute premium for playing music in real-time across the internet, we've focused first on the desktop, where we have the most control ... but still find a ton of challenges.
If you saw this recent article about Android and audio latency, you can see why there are challenges in the mobile space: https://news.ycombinator.com/item?id=9386994
If you were to try and build a web-only version of JamKazam, WebRTC is your best bet but it does not have low enough latency, either.
Just a week ago we released our 'distributed metronome', which lets musicians hear a synchronized metronome regardless of how much internet latency there might be.
Dedicated QA teams should be avoided unless truly necessary. Otherwise, you have the same problem of developers throwing over under-tested code to a group of separate people that are smart but treated poorly.
A QA guy who loves to write automation gets the same promises... "oh you'll be programming mostly; manually test maybe once a month". But when they get into the door, it's the exact opposite.
Developers should all be passionate about QA (read as: the quality of their product), as well as how their product is actually deployed (read as: executed in the most important of environments--production!).
This is running the Linux real time kernel to help us achieve extremely low latency and I/O jitter. We've had to do a ton of fine tuning to get the latency as low as it is.
Our website is built on Ruby-on-Rails backed by Postgresql. We are using Resque for asynchronous jobs, and a Websocket/RabbitMQ solution to help with events in the browser and events else where in the backend.
Our JavaScript is a homegrown mess (jQuery and, ahem, 'business logic'). Having kept up with the latest web tech mostly through HN, I'd take the React/Flux plunge if starting from scratch; I'm still looking for an excuse to start using them anyway, even if just for part of the site!
Anyway, we are very excited to be starting the KickStarter for the JamBlaster, because it's your best way to get the latency low enough to have a really good jam session.
/me fingers crossed
After working at my current startup, I realize I was wrong. We are an entirely remote operation, and have been since day 1. A few of us are in Austin, and rarely meet for a face-to-face, but it's more of a 'oh yeah, you actually exist' meeting rather than a hash-it-out sort of meeting.
I think the reason we have been successful is because being remote has forced us to write things down, in our wiki (in the form of product specs) and in JIRA (in the form of specific features and bug fixes). With just those two forms of written communication, we've solved 95% of our communication needs. We almost never skype or use video conferencing... it's just not needed.
The other reason we are successful is due to experience. We've all done startups before, so we know the drill. I can't emphasis how important this is enough, but does deserve more explanation. (unfortunately I can't muster the amount of typing atm).
IN the end, we can focus on getting work done... without the distraction of office chatter, commuting, long lunches.