They were entrenched in a few niche markets: Education, Music Production, Desktop Publishing. Photoshop, Pagemaker, ProTools were all Mac first, so that's where the users were and they were locked in due to files, plugins, fonts etc.
2,124 karma · joined December 18, 2011
I guess it's just easier to say 'GPL bad' than actually explain copyright to every developer.
Samsung alone outspends Apple on marketing. Samsung needs to continuous battle against the other Android phones.
If you want an Apple phone either you pay what they are asking or you don't get it.
This is not a requirement of the LGPL, the rest is. A user must be able to replace a LGPL portion of a program. Dynamic linking is the way this is usually accomplished.
By contrast I think C++ and realtime audio programming is simple, but I've slowly picked it up over almost 20 years. I retreated back to desktop apps and firmware. I'll take another stab at learning web technologies, but not at a startup where I need to deliver asap and learn at the same time.
As much as developers hate sandboxes, the lack of one (except Mac OS until recently) is why I think desktop is failing. Users just don't feel safe installing random software like they do going to websites or installing mobile apps. Users have been conditioned to only install software from sources they trust, and they trust no one.
If I post a link to my new web project, most people will click on it. If I post a link to an .exe almost nobody will download it. I think that's the main issue killing the desktop. Big downloads, compatibility issues, slow installs are also an issue, but I think they are secondary.
USB has several transfer types: interrupt, bunk and isochronous.
Interrupt is initiated by the device so it wouldn't help you read variable amounts.
Bulk is good for mass data transfers, but has guaranteed access to the bus, so you'd possible get audio dropouts when accessing another USB device.
Isochronous can reserve bus bandwidth and have latency guarantees, but must occur on a fixed schedule. Since they are on a fixed schedule, they always have the same amount of data, hence a fixed block size.
Since data is arriving at the OS in fixed blocks, the lowest latency way to handle the data is deal with the blocks when the arrive. If you wanted to read variable amounts of data, you'd need to add a buffer on top that could hold a variable amount of data which would add latency.
Copying variable amounts of data isn't slow, but dealing with dynamic memory allocation is. If you needed to allocate a different sized block every few milliseconds you'd be spending the majority of your time allocating memory rather than processing audio.
This system can work very well: OS X, iOS, Windows and Linux can all get very low latencies. The issues with Android has nothing to do with block sizes, but something else in it's architecture.
Why do you say this? The USB audio card (or similar) is generating blocks of audio at a fixed rate, no?
Maybe for video playback or games you need to synchronize audio and video, but there is no need to do that for music production apps.
If you are writing some sort of synth, as soon as you receive a midi note or a tap, trigger the synth and the note will play in the next audio block. No need to wait for the GUI to update.
If you are doing some sort of effect, grab the input data, process and have it ready for the next block out. I don't understand why you need a second loop.
In the 80s / 90s, computers were very expensive and it was common to only buy exactly what you needed. PCs excelled at this. Everything was an option: Video card (MDA, CGA, EGA, VGA), ram, hard drive, hard drive controller, serial port controller, sound card. If you later needed more capabilities you upgraded whatever was necessary.
As computers became cheaper, upgrading began to make less financial sense. Upgrading a component and paying for it to be installed became almost equal to the cost of a new computer. There also became less to upgrade, onboard sound, network, etc was good enough. The only thing left to upgrade was CPU (but usually required a new motherboard) and video card. Upgradability which was originally a huge selling point became a niche feature.
As integration continued, size, weight, power consumption all became more important than upgradability / customization. Hardware wise, all Android phones and the iPhone are pretty much the same.
But randomly selecting an id doesn't make much sense. For example here are all the ids Linux knows about: http://www.linux-usb.org/usb.ids. Obviously don't select Logitech, Microsoft, Canon, Samsung, etc. manufacture id. Either select an unused manufacture and then randomly select the device id. Or select a manufacturer id that is no longer used like US Robotics (I doubt they are making any new modems) and then randomly select a device id.
As soon as make your device, connect it to a Windows machine which will try and find a driver -- if it doesn't, probably no conflict. If there is a conflict, it's with a product that distributes it's driver manually - so you don't have to worry. Or a product that doesn't exist yet, which could be an issue.
I took a quick look through https://books.google.com/ngrams/graph?content=%22open+source... and I couldn't see the term being used in a software context before 1998.
I've had a better experience when doing firmware upgrades for mature products, but has anybody had a good experience developing hardware products with a work from home team?
I've read their FAQ and I won't participate in Kickstarter. I consider it a bad deal. If I see something on Kickstarter I want, I'll wait until it gets retail release and buy it for probably the same amount and have no risk. And if it doesn't get a retail release I'll live without it.