cdawzrd

Congrats! Looks like a very clean app.

Because it isn't clear from the launch page: can it play sounds? I'm wondering if it can "audition" chords so that I can get a double-check on whether I'm picking the right one. I'm a musician who mostly plays by ear and improvisation, and I sometimes have to spend an annoying amount of time figuring out the correct name of a chord if I want to write it down for another musician to play. (a feature that showed which notes made up each chord, maybe behind a long press or something, would also be handy for this)

I have used QML with good success in an embedded environment, although the embedded processor I was using did support OpenGL. If you want to use QML in even more constrained systems, it looks like there has been some work done on this [1], but I haven't tried it to see what the limitations are.

[1] http://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2...

The latest high-end PCB tools actually provide useful autorouting features, because they have figured out that if you combine human ability to solve the difficult pattern-recognition and planning problems, you can have a computer solve the details.

For example, Xpedition's sketch routing feature: https://www.youtube.com/watch?v=fIi13gI9xEA

Routing 4094 signals sounds daunting, but it is a bit less daunting when you realize that a good fraction of them are power/ground (and route directly to planes), and the rest of them are mostly logically organized into buses/groups that can be routed together.

Having used both REAPER and Pro Tools professionally, my opinion is that REAPER is not basic at all -- it has every feature I have needed in a DAW, it's easy to use (for me, at least) and performs better than Pro Tools, at a far lower cost. It is one of my favorite pieces of commercial software.

RF Explorer is a "budget" option at around $300-400: http://rfexplorer.com/models/

Professional handheld spectrum analyzers are in the $3k-50k range from the likes of Keysight, Anritsu, etc.

Feature requests for Issues: priorities, and states other than open and closed. These are the biggest things keeping us from using GitLab issues rather than an external tool.

We need to be able to set priorities (ideally customizable, but at minimum high/med/low). We can kind of do that through labels, but it's messy because you can only search for one label at a time (no boolean combinations of labels).

Right now, when you assign an issue to a user, it's considered "in progress", and from there it can either be unassigned or closed. It would be nice to separate the state of the issue from the assigned user, since in our current workflow we assign many issues to a user, but that user might only be working on a few of them at a time. Using our current bug tracker, we can differentiate between "Open, unassigned", "Open, assigned", "Open, in progress", "Fixed", "Verified", "Closed", etc. I know having a completely customizable state diagram for issues is a big software task, but maybe there is some intermediary level of complexity that would allow better tracking of what is actually being worked on now vs. what is assigned to people.

No, LTSpice simulations are not real-time. However, there have been attempts to make that happen[1]!

[1] http://www.livespice.org/

Probably the most affordable way to get some confidence is to connect two computers at either end of the cable and do a transfer speed test using iperf or something like that. If you are using random unmatched computers, do a "control" test with a short, high-quality patch cord between them to get a baseline performance measurement.

Well, not quite the same thing... the TP-Link product is 2.4GHz only, which is kind of a big deal these days. Support in DD-WRT and Tomato for 5GHz and 802.11ac protocols is somewhat shaky today (on some devices at least), but hopefully will improve.

Try running it under qemu[1] or bochs[2]. A "virtual machine" software such as VMWare or Virtualbox is not the same as a low-level "bare metal" CPU emulator such as the two I suggested. The latter programs make assumptions about how the guest OS will behave that probably aren't valid for this project.

I suggest starting with bochs since this project has a bochsrc.txt in the git root that will be automatically picked up if you just run "bochs" in that directory.

[1] http://wiki.qemu.org/Main_Page

[2] http://bochs.sourceforge.net/

Pedals are still the state of the art. Why would any performing musician want to use a smartphone instead of something designed to be controlled by feet, even if Android had something close to real time audio (it still doesn't)?

*512MB. This is not an Apple innovation... I believe all SSDs have caches hanging off of the controller, used for both write and read. Flash memory is very much slower than DRAM when writing. This DRAM cache is why many SSDs have better burst performance than sustained write performance. Only the most high-end datacenter-oriented SSDs have backup power, typically supplied by supercapacitors rather than batteries though. I don't see any backup power on this Apple SSD.

Not really, depending on the engine. Some engines are built sturdily enough that they can make that power without anything other than bolt-on modifications. For example, the Saab B204L turbo engines make 185 HP stock. Just by changing the mapping in the ECU, you can raise that to 225 or so. Add a new exhaust and intercooler, you're up to 280. Bigger turbo, now you can hit 300-330. Bigger fuel injectors, now you can hit 400. Keep adding more air (bigger turbo) and more fuel (bigger injectors) for as long as the engine can take it. I think the record is currently around 700 HP, which may have been done on an engine with aftermarket pistons, but still, 400HP or more is possible with only bolt-on modifications, no rebuilding of the engine internals.

Their parts presumably take about 22 weeks to manufacture and get to the end customer. They probably cannot afford to build the parts ahead of time and stock them, so they only kick off the factory once they receive the order.

In the case of small orders, manufacturers may wait to start a production run until enough orders have come in to make it worth it, which can mean long lead times for someone who only wants 100 of something

Many hobby things with USB ports are using the default VID/PID from the chip vendor (generally FTDI's USB-to-Serial converter chips, or the on-chip USB controller of Atmel/Microchip/etc's microcontrollers).

Using your own VID/PID allows you to write and distribute a driver that can be tied to your gadget rather than using a generic driver. Widely distributing products (even if they are "hobby stuff") that re-use the microcontroller's default VID/PID is also usually against the license agreement with the chip vendor and can lead to problems down the road.

Considering that an injection molding run takes ~$100k minimum to start up, it's not that surprising.

realistic Apple environments :-)

(I realize there are one or two Android and Windows phones in the list, but still...)

With companies like OSH Park[1], the cost barrier to getting a bare board professionally manufactured is so low that you ought to just try it sometime. If you already sketch schematics, go through a basic Eagle tutorial or two, then try laying out a simple board based on your schematic. If you keep it small, you'll only be out $15 or so!

[1] http://oshpark.com

Yup. You can't take 6 Google Glasses and suction-cup them all over a car.

I don't like this trend. A modern self-hosted forum is badly needed. We've moved away from the time when any self-hosted web software had to be written in PHP now that many turnkey web hosts support Ruby and Python (and VPS hosting is cheaper), but the software hasn't caught up yet.

I use Subsonic to solve that particular problem. Works well if you have enough upload bandwidth.

That's great for web developers, but what about those of us who are building desktop or embedded software?

I run PyCharm in 64-bit linux and have no font problems. Perhaps you should ask in the Jetbrains community forums, and include some more details / screenshots?

Bad firmware updates are (almost always) recoverable, just not always (easily) by the end user. What happens when you lose power is that you need to use the hardware-level debugging/testing functionality of whatever programmable device is in question--JTAG, for example--to load a running firmware image and then reprogram the half-programmed flash storage.

You don't need that kind of gear to build a board like this. You just need a good set of EDA tools and to read all the datasheets carefully. Stuff like trace impedance and the performance of high-speed lines should be done in simulation tools before you ever send out the board to be fabbed. It's only in cases where people are really pushing the limits (networking gear, RF gear, for example) that high-speed physical measurement hardware is necessary.

A board like that, with a Spartan6 and ARM processor, is actually fairly easy to make work "out of the box" with minimal attention to pre-build simulation, as long as you carefully follow the datasheets' recommendations for signal routing, bypass, etc.

Actually, it should be trivial to defeat without MATLAB:

1. Take the recording of interest 2. Use any audio processing software to apply a 400Hz-4kHz bandpass filter. If you don't have audio processing software or a computer, you can play back the recording over a phone. 3. Play back the recording via cheap computer speakers (no subwoofer) or over a telephone, and re-record

Low-end speakers don't have much output below 100Hz, so the new thumbprint from location (2) will replace the old thumbprint. The harmonics of the old will still be there, but bandpassing starting at 400Hz will cut out the strongest ones and make recovery of the original thumbprint very difficult.

Until there is a open-source program that replicates what Ableton Live offers (seamless and easy-to-use integration of audio recording and nonlinear editing with MIDI production), no one will consider using an open-source tool.

The biggest hurdle from my point of view is that low-latency audio on operating systems that are not Windows or OS X is a joke. Some organization needs to sink and huge chunk of developer time into either improving the user and developer experience of JACK or writing something new. Maybe once that is in place and starts shipping in vanilla Ubuntu (no special kernel requirement either!) the user software developers will be able to start catching up with the tools available on the Win/Mac platforms.

Something that most people who aren't in product engineering don't realize is that sourcing small displays is incredibly difficult if you are not building smartphones. All of the nice displays you see coming out and going straight into phones are simply unavailable to anyone looking to build a lower-volume consumer device (where "lower-volume" here means less than a million). If you want to build a product with a small display (and don't even get me started on touchscreens), you are stuck with old technology, very limited choice, and high prices.

I like that the name can be a pun, "Updated-itis: a disease where the afflicted person cannot help but check hourly whether all of their software is up-to-date"