Hacker News new | past | comments | ask | show | jobs | submit | cdawzrd's comments login

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)


No sounds just yet - but that is a planned feature. The sounds of the chords will play every time a chord is input, and upon tapping any given chord, for feedbock.

Interesting suggestion about showing the note names that make up each chord! The data will definitely be in the app when sounds are added, I'll have to think about adding that.


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.


Yeah, a good portion of those pins will be wired directly to the power regulator components that are next to the socket, and a good chunk more break out neatly into channels for memory and PCI-e.

Seems like it's almost boring these days since everything's encapsulated in a layer of abstraction. A lot of the more complicated wiring is in breaking out PCI-e channels into things like ethernet, audio, and other miscellaneous ports that involve good chunks of analog circuitry.


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.


Cost is low but 3rd party ecosystem including plugins is weak. It s like notepad++ of programming editors or winamp of music players. Effective, cheap, non innovative Yet OK.


I've only used Ableton, FL and Reason, so there could be something I'm missing, but doesn't Reaper support vsts? How could the ecosystem for plugins possibly be weak?


VST/3/AU/DX, and it supports scripting your own in JS as well. Unless they're upset about not having LADSPA or Nyquist, I can't imagine what else they'd be referring to that isn't proprietary AVID garbage.


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.


Many vendors will also rent out them by the day. There used to be a company in Denver that did back in my WISP days.


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.


Actually you can add priorities to labels :) http://docs.gitlab.com/ce/user/project/labels.html#prioritiz... You can also search for several labels in the current release. Just select some in the dropdown :)


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

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


Have you personally been able to get anything to actually work in livespice? I've observed that it's UI is so broken that it's practically unusable


Can you say what's broken about it? Is there something that prevents you from following the tutorial to build the low pass filter?

A lot of people have problems with audio IO (the ecosystem of audio devices, drivers, OSes, etc. unfortunately is a minefield) but I haven't heard many complaints about the UI.


I'd have to open it up again and try to do something with it to remember.. I think it was like I'd drag something onto it, but then I couldn't delete it, and a few other unintuitive things.. and yea, I never could get the audio IO to actually work


Delete should just be the delete key... I think there was also an item on the edit menu to delete the selection. I tried to make it behave as standard as possible (the usual windows shortcut keys for cut/copy/paste/delete/etc.). There's an annoying issue in the GUI framework I used where the right part of the UI has to be in focus for these things to work. Maybe that was the issue.


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.


Why is 5GHz a "big deal" rather than a "nice to have" (but no big deal if you don't)?


2.4GHz has three non-overlapping channels. At max bandwidth, it has one non-overlapping channel.

5GHz has twenty-one non-overlapping channels.

In an apartment building, where you're pretty much guaranteed to be in close proximity of at least a few other active routers, 5GHz is a big deal.


Heck, I live in a detached home and have 14 visible networks from my living room.


Ah, that makes sense. Thanks.


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/


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

Search: