It’s writing colloquially… the writer has the difficult job of describing something that’s happening inside this cabinet over time and space and other dimensions
Imposed by the game and players behavior.
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.
If you had lived through the last blackout and still lived in Texas, then absolutely yes it’s newsworthy. We want to grade our government accurately. Almost having a collapse again is a bad mark on the test score.
JamKazam founder here. Happy to come across a user!
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.
I've been experimenting with it too, with my funk band. Very quickly we realized that any latency was too high for us to have a hope of getting in the pocket, but it worked quite well for sloppier rock jams.
Since you're here, I'll ping you some feedback:
- The UX is, charitably, idiosyncratic. We all found it hellaciously difficult to get started, find each other, start a session that didn't have strangers popping into it, manage audio (more on that below). The UI is honestly just super crazy insanely weird.
- The audio handling is... counterintuitive too. I expect to be able to control my "monitor" mix, and have one person control the master mix. But that just isn't working. Instead of one channel strip per source, we just each see a single fader for each participant (even though each person has vocal mic and instrument mic) and it seems to affect everyone globally.
- Everyone slows down over the course of the song. We're all listening to each other, so the latency builds, and we all end up dragging horribly. Only solution we found was to have the drummer play to a click which is miserable in our genre and generally not fun outside of a studio session (which is "work" anyway).
I _really_ hope you're able to use some of the newfound interest you've got to inject some new life into the service. The core is so promising. Notwithstanding that feedback, I'd pay $10/mo for a non-social private version where I can host my own server, since all my bandmates are within a mile of me.
I think JamKazam is helping some of my friends maintain what little is left of their sanity in the current climate, so thank you for that!
Unfortunately I might not be in many sessions for a while as I replaced my last Windows machine with Linux this weekend, which I don't think you support yet; although I will have a go at getting it working in WINE :)
Hi! This was already asked before, but probably my voice would be heard: do Jamkazam team support Linux? Currently we're using Jamulus for practicing, but I would like to compare it with Jamkazam. Unfortunately, some of our members are *nix guys.
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.
Not at all. Unity is the engine I use, these engines are immensely valuable to developers like me, I can't invest years into building my own stable core right now, and although it has its rough edges and problems, it suits my projects very well. Builds to all sorts of targets, too. For my latest project I'm using the FMOD middleware for positional 3D audio. On the graphical asset side of things, I paint everything in Photoshop, and animate it in the amazing animation software Spine (which has an open source Unity runtime).
Oh man, Spine is amazing. The latest 3.0 release has some great new scale features, and the fact that you can browse all the runtimes on github and submit patches is just the best. And the community is great too, lots of support on the forums, and bugs I've reported were fixed in days. So yes, Spine is absolutely worth the investment.
We have a desktop application that uses QtWebkit for the UI.
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)
+1 for using a wrapped-web stack approach. We've recently taken another look at the Electron/NodeJS/WebSocket stack - it allows you to build a native app using web technologies, even calling native (WinAPI) calls. This space has really come a long way recently.
We have a website presence too, and the website UI (as visited in a normal browser) is 95% the same style and functionality as the desktop app.
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.
Atm we use a mix of QtQuick/QML and some widget code mainly when wrapping QtWebKit it for some parts of the app furniture that need it.
Although the guts of our app requires native code (for clipboard monitoring and websocket message receiving), were considering ditching much of the UI in favour of a webapp.
Can you comment on your experience? One of my doubts is if I should go the QML / Qt Quick Controls way or the standard Qt Widgets (with PyQt).. For instance, do you think you could implement your app's interface with Qt Widgets by itself?
The problem is that I know how far I can go with Qt Widgets, but on the same way, I would like to build something more "modern" and Qt Widgets may be quite limited..
I could have implemented it with QtWidgets, however I had found a decent UI widget library that suited my use case very well ([1]). Hence went with QML/QtQuick.
My advice - just do it :-). If you want to build a cross-platform desktop app then go for QtQuick/QML/C++. QtCreator has a bunch of example projects. Use those as reference. The Qt docs are solid. Worst case - you will learn that Qt/C++.
I am not a big fan of PyQt/PySide, especially when starting fresh with Qt - you would have a hard time figuring out how everything fits and where the issues are.
I have used web-based task/todo lists (trello, asana, etc.) but I wanted something that could be used offline - my work does not allow storing company sensitive data on 3rd-party servers.
Started the project with Electron, using AngularJS and Angular Material. That allowed rapid prototyping with a slick UI and it was fairly easy to find additional Angular-based plugins. My main motivation in selecting Electron and Angular was to learn the two technologies (easier to learn something by doing a project in it). Screenshot: http://imgur.com/NZzEFKX
Had a few issues with the Electron app - big download size (50-70MB zipped), no print functionality, app felt non-native, very convoluted process to get it published on the Mac App Store.
Decided to change the tech stack to Qt/QML. I have published C++-based games, built on Cocos2dx. Wanted to try Qt to build a serious app.
Gumroad has been a slick experience - I have opted for the fully functional trial option and let the user buy a license to use beyond the trial period. Gumroad's onboarding (buy workflow) and tech (license key generation and validation) have been a revelation.
Qt has both commercial and LGPL licenses. I think you can develop commercial applications with LGPL and not distributing the source code of your own app, but you can't statically link to Qt's libraries. https://www.qt.io/qt-licensing-terms/
That's not correct. You can use the LGPL version of Qt to develop commercial product without paying for a license and while keeping your source proprietary. You aren't allowed to statically link Qt under LGPL, but that isn't a big deal.
