12-10-2009 11:28 AM
First I try to make a flashlight using the video capture player - FAIL
I try and almost succeed at making a guitar tuner:
Simulator runs many times faster than the phone, making FFT tweaking a pain in the arse. How 'bout throttling, PLEASE!?!
The simulator supports PCM. I actually had a chromatic tuner working! IT FREAKING WORKED! IT showed note and cent offset. So many hours just to find the phone says the PCM encoding is not supported - FAIL
Why the hell do they put these things in the API reference (which is practically useless for a n00b like me) when they've crippled the phone. Apparently they didn't want app developers to do anything clever.
I hereby abandon BB development. It's now apparent why cool apps like this don't exist already. Because they cant. Should have gotten an iPhone.
12-10-2009 12:21 PM
BlackBerry - useless.
Ok, I've made a note of it.
I understand your frustration (we were all noobs at one time), but these issues exist on every platform I've learned over the past 25+ years. You either slug through it and join the ranks of the "experts" (or at least "competents"), of you give up in frustration.
I remember feeling the same way about the Windows, back when the early versions were released.
...and I think it took me 2 years to learn MFC on Windows (after C++ was released)
...and just when I had the event mechanism in Java figured out, they changed it (twice).
12-10-2009 01:41 PM - edited 12-10-2009 01:45 PM
Thanks for the encouragement. I've been programming for about 15 years. From microcontrollers to symmetric multiprocessors to GPU, windows to linux, lua to assembler. I actually hadn't used Java before (though read it several times) about a month and a half ago, when I rediscovered Robocode (program robots to fight eachother, I highly recommend it) - which used to be great in zasm. After this long, and with the amazing guidance from Eclipse, I'm pretty solid with Java already. Even still I find the learning curve with their API feels quite steep, and it doesn't help that there are so many different versions and platforms. You don't even know what your hardware is gonna support. I really think someone made a bad design decision with the lack of PCM encoding though. That's the native sampling format, and it exists on other phones. I'm pretty sure someone would have had to say, "let's take this out."
Now that my frustration has simmered a bit, I'm not completely against black berry development. But I'm out of ideas. I'm not really into making a new tweeter or something beat to death. I'm more of a stand alone app kinda guy. In any case, if I do have a brilliant idea, you can bet I'll be coming around here first to check the feasibility. Never had that kind of problem before - having and being unaware of hard limitations.
On a last note - I could try to use the AMR encoding, but I don't know anything about it and decompression scares me. On top of that, it's already a push to do the FFT fast enough to get the frequency domain (for the tuner part) - how cool would that be if there was an API to use the DSP on the phone to do stuff like that which is what DSPs are built for (I looked, crossing my fingers, no luck?). On the other hand, I just considered that the ARM compression may already contain frequency domain data, which could illiminate both problems... definitely worth more research. Though since the compression is suited for speech, the audio may not be good enough for precise frequency detection. Anyone got any tips on that matter?
12-10-2009 05:17 PM
Two things, one you could post the idea of having access to the DSP in the Issue Tracker. It would at least put it in a place where it can be checked to see if it will get implemented or not.
Second: The Storm doesn't support PCM? I don't know what OS you are using (4.7 or 5.0) but at least on 5.0's documentation it presents all possible encoding formats and PCM is supported (at least in the documentation). If it really isn't supported then that is definitely something to put in the Issue Tracker either under API to add support or Documentation to remove it so others don't try to use it because it is there.
You have a lot of experience, I'm sure you can do some amazing app(s) if you put your mind to it. Good luck.
12-10-2009 07:45 PM
As for the OS, I'm using 22.214.171.1248 on the phone, using the 126.96.36.199 simulator (9500). Since the place I found specifically said that the CDMA ones are the ones that don't support PCM, I can guess that GSM does, hence the simulator supporting it. I've been using the 5.0 API reference, so yes, that's where I found the string for the capture:// stuff.
I just made three new issues in the tracker, the encoding problem, the simulator being too fast, and accessing DSP functionality. Maybe something good will come of it. *shrugs*
12-10-2009 08:08 PM
At least it is there now. Can you post the links to them? I could definetly use the DSP support in some apps I am working on.
12-10-2009 08:18 PM - edited 12-10-2009 08:33 PM
Simulator too fast - https://www.blackberry.com/jira/browse/TOOL-68
DSP capabilities - https://www.blackberry.com/jira/browse/JAVAAPI-699
Recording problems - https://www.blackberry.com/jira/browse/JAVAAPI-698
Ummm... so I've been experimenting with some more encodings:
FORMAT SIM DEVICE
pcm y n
audio/basic y n
ulaw n n
audio/x-wav n n
gsm y y
GSM is the only one I can get to work on the phone. Still has to be decompressed though. I've also noticed that doing things like &rate=44100 have no effect in the simulator for pcm, and can't test for the device.
12-10-2009 10:22 PM
Weird, in my "rule book" that is definitely a bug. If you support a feature enough to put it in your simulator but not your actual device then something is not right. Its good you are testing that.
12-15-2009 02:59 PM
rcmaniac25 - I Don't know about that, use a 4.6 sim and scroll the mouse wheel and look at what events it is throwing (hint its not NavigationMovement)
Some stuff just happens in the sim that makes little sense. I am aware of talk from DevCon LAST year that some encodings are exclusively supported on CDMA and others exclusively on UTMS devices. My thought is it has something to do with the dsp/atd on chip depending on the Chip Manufactorers. So they enable is on the sim because who ever wrote the DSP simulation wrote it for a UTMS device.
12-15-2009 07:42 PM
It is very possible and most likely the case.
I felt that it was a bug because when you go to develop a product you often develop it for something, in this case an app for a BlackBerry. If you can develop the app but you can't get it to work on the "thing" that you are developing it for then either you did something wrong or the thing you are developing for has something wrong with it. coder0xff seems to know what he is doing so if he wrote the code right but it doesn't work then I would consider it a bug. Often you can download the simulator of either CDMA or UTMS so if it is enabled for both then I would expect it works for both.
If they only had one simulator available then I would understand but they have more then one for all but the newest BlackBerrys.
On a "slight side note" I would rather have a slower, software emulation of something then to have it available for developers but no way to use it on the actual device unless you are developing for a specific "subdevice" like CDMA or UTMS.