Funiculus 0.50 is out

I really think you should've left a settings menu in with the option between "free note" selection or "standard guitar tuning"

Also, is there a way you can make the pitch stay on the screen longer?
I play a string on my guitar, and it flashes "E2" and a red bar 2 from the left (which means it's slghtly flat..) but it only stays on the screen for half a second before resetting itself to B0.

Just some suggestions though. You might also want to have a page that you can go to that gives lists of scales for knowledge purposes.

C D E F G A B C
D E F# G A B C# D

Etc... Just for the use of GCSE music and composing. :)

Thanks :)

I suppose the pitch could stay on longer, but it's really supposed to be on the screen as long as the sound is there. If you aren't playing very loud, it will give out sooner. If another tone of some sort is playing in the background, the note will often register lower than it should. But there's probably no harm in leaving the old note on the screen...

The tune-by-string method was somewhat defective because it was unable to pick up low E, and it really gummed up the UI. It is going to be replaced by a totally new system that will allow users of guitar,mandolins, banjos, and whatever else, to select a tuning. This will be different from the old system in that the user won't have to select a given string.

Any chance in the future for a setting to turn off (or extend the time of) the auto shutdown feature?

Well, I know next to nothing about how to tune a guitar. I liked the old system where I just selected the standard guitar tuning, and pressed the letter of the string I was trying to tune (I had to guess even there, but I figured the first one was the big string :).. No, really I'm not joking..).

I can understand going to a better system with a better algorithm, but it would still be nice to have something in the settings that would let you say something like "I'm trying to tune a standard guitar" and have it print the appropriate help on the main screen. Maybe even just a list of the strings and what note to tune them to. Even better might be a wizard of sorts (optionally turned off for the people with a clue) that walks you through tuning whatever instrument you have selected.

Thanks BTW, for such a great application. The guy at the music shop was very impressed (even with the old version) at it's accuracy which helped me save some $$.. (My wife hates my iphone, but he talked up your app so much and how well it worked that I didn't have to buy her a tuner or continue taking her guitar to our neighbor to tune). Someday maybe she'll even pull out her guitar for dummies book and try to play it.

Si :
To change autoshutoff time, download Erica Sadun's plutil utility, and also MobileFinder and the text editor for it. Also Mobile Terminal.
Go to the preferences directory by running Mobile Terminal and typing:
# cd ~/Library/Preferences
then type:
# plutil -c xml1 com.mauvila.funiculus.plist

This will convert the preference file from binary to xml.
Then run MobileFinder, find the com.mauvila.funiculus.plist file, edit it with a text editor, and change the "funiculus.autoshutoff.length" setting...it is the number of seconds to wait. It should be 120 by default.

Jeff:
The new hands free string tuning system is on its way, but it involves "live graphics" which I have to figure out first.

First I want to commend you on such a great program. The tuning is really spot on. The only problem I am still encountering, even with the new version is battery life. As soon as I install and run Funiculus and close it out, the rest of the day my battery just drains. I don't know if processes are still running for some reason or what. As soon as I uninstall it my battery life is back to normal. With Funiculus, off a 100% charge in the morning I will be at 40% at night. Without it I will be at 60-70% at night.

I've never heard of anyone encountering battery problems with Funiculus, except for those who left the old version running while the phone was in standby. I certainly haven't encountered anything, but I'm running 1.1.3, and I don't know if earlier firmware version behave differently. I don't even get as low at 70%...I typically end the day near full, even after using Funiculus a while.

There is an easy way to check and see if Funiculus is the culprit: download Mobile Terminal (or better yet Tapp). And run it, and type the following command: top -l1

This should give a list of the current processes. Look at the one called mediaserve. The third column after the name (#TH) should show the number of threads. Check this before and after you run it. If it stays elevated after running Funiculus (e.g. goes from 14 before running to 15 afterwards), then definitely let me know, but it shouldn't happen. The "good" number is 14. In the old version, exiting using the home button left a chance of going to 15, but this was fixed for the new version, and it was remedied by using the exit button.

Since you say it happened with the old and new versions, which use a completely different threading system, I suggest looking for other culprits. Wifi issues, as well as SSH, can run down the battery. If you still believe it is Funiculus, let me know...it could always be a weird firmware bug of earlier versions.

I checked out the threads before and after using Funiculus and it was set to 14. It's just so weird that once I install the program my battery life sucks, and as soon as I uninstall it, it's back to normal. I'm on firmware 1.1.1 should have mentioned that last time. Yeah I make sure to turn off Wi-fi and SSH when I'm not actively using them, and have tried a couple different scenarios when I've had Funiculus installed. Like using the home button instead of the exit button to close.

What would really be the tell tale sign of it still running in the background is after I run it to turn the phone off and back on to see if that affects the battery life. Maybe somehow something is lingering in the background??? I'll give it a shot sometime this week, I'll start with 100% charge and run Funiculus in the morning after taking it off the charger and then once I'm done running it I will turn the phone off and back on to see what my battery life is like the rest of the day.

That's odd...Funiculus defintely doesn't do that for me. I tested it myself the other day, starting with a fully charged phone (1.1.3), and I ran Funiculus a number of times throughout the day without charging it. 24 hours later, the phone was about 95% charged. Again, I'm on 1.1.3...for all I know, 1.1.1 could have a bug in it.

Interestingly enough, I remember that when I was on 1.1.1, running the iPod program would often elevate the MediaServerD thread count to 18 (if I remember correctly), and it would stay elevated for a while. When I updated to 1.1.2, this behavior seemed to disappear. (Does this happen with you?) So it very well could be a firmware bug in which threads aren't disposed of properly. The only thing is that you say it happened on a previous Funiculus version as well, but the latest version uses a completely different system.

If Funiculus were the problem, uninstalling it wouldn't immediately change anything...the culprit would still be in RAM, and uninstalling merely removes stuff from the drive. And it would probably remain in memory until a reboot. Likewise, rebooting will clear the RAM, even if files are still on the drive. So if uninstalling immediately fixes it, it's likely a coincidence.

At this point, I would keep your eyes open for other offenders...it seems unlikely that it is Funiculus. But anything is possible, and if it still keeps up, let me know...should it ever turn out to be Funiculus, I would do my best to fix it and have a new version out stat...

I'm using firmware 1.1.1 as well, and I can confirm that there are some remaining power issues. I think you have to run Funiculus once to cause the problem.... I had updated things a while ago, but had never used the new version, and everything was fine. I used it last night to tune my wife's guitar (looked some things up on the internet, and I think I did it correctly ;), and this morning I powered up my iphone to get the red bar/battery warning screen (warning, you're below 10%).. I had exited Funiculus using the exit button on the screen, not the home button.. When I check my usage I've got about 15 hours more usage than I would normally expect. When I powered off my phone after the guitar tuning, I had somewhere between 2/3 & 3/4 battery remaining which would normally last me a couple more days of standby time, and even then it wouldn't be starving to death ;)..

I'm pretty sure that if I do a real power down, and boot back up again then my battery stops sucking itself down...

If you'd like, I could probably set up a way for you to ssh to my phone to experiment with things.. I don't know if you really want to fix the problem for firmware 1.1.1 or not.. I've been meaning to update to 1.1.3, but I've never had the time (it's strange because I run linux, and it looks like I have to go to 1.1.2 before I can update to 1.1.3, which means I need a windows box to jailbreak 1.1.2.. I don't know how many other people are in my boat, but I suspect not many, and I certainly plan to update when I have the time.. until then I can just reboot)..

-Jeff (jeffb (at) umci.com) Mail me if you want a phone to experiment on remotely..

Yeah, that's funny...if there is a difference between the firmware versions, I'm not sure what I could do to fix it, unless I knew exactly where it was coming from. Have you tried running "top -l1"? (I recommend saving the command in the Tapp program...) If you do test it out, looking at the MediaServer one, also try running the iPod program just for my own curiosity. I think 1.1.2 changed something to do with audio.

Did the previous versions of Funiculus do this too? One thing the new and old versions have in common is that it lets the system take care of handling certain aspects of Audio. Perhaps 1.1.1 doesn't handle this right...I've got a new version (0.60) coming out in a few days (with a new guitar tuning selection, plus a bunch of other random features)...anyway, I may see if I can manually handle this part of the audio for older (1.1.1 and earlier) firmware versions.

And if you really want to experiment, if you can establish that Funiculus is a problem, try running Garf afterwards...if it's an audio thing, Garf might reset the system's audio, thus avoiding any drain. (The whole exiting by home-button isn't an issue anymore with Funiculus 0.50, btw)

Again, I don't have any problem with this, but I'm on 1.1.3. And I also use a newer unreleased version of Funiculus that's gotten rid of the pause at the beginning. But even before then, I've never noticed my battery going down.

I'll try to test some things later when I have a few minutes.. It's tricky to spot battery drain except for over long periods of time :).. I wouldn't worry too much about it though.. (especially until someone gets you better info).. I don't think there is really any reason that most people can't upgrade to 1.1.3 to fix this.. I've seen a number of apps already the refuse to install because I'm not running 1.1.3 yet.. Seems like one of those things that will just fix itself with a little bit of time.. :)..

OK, I decided I had time right now.. (what the heck, it's only work)..

Processes: 21 total, 1 running, 20 sleeping... 79 threads 15:05:41
Load Avg: 0.55, 0.24, 0.09 CPU usage: 16.7% user, 83.3% sys, 0.0% idle
SharedLibs: num = 0, resident = 0B code, 0B data, 0B LinkEdit
MemRegions: num = 1794, resident = 14.6M + 0B private, 26.5M shared
PhysMem: 19.3M wired, 18.6M active, 17.1M inactive, 55.1M used, 46.2M free
VM: 169P + 0B 8462(0) pageins, 0(0) pageouts

PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
48 top 0.0% 0:04.800 1 17 46 300K 524K 0B 2.22P
42 sh 0.0% 0:04.800 1 13 31 368K 1.38M 0B 4.55P
40 sshd 0.0% 0:04.801 1 14 30 328K 680K 0B 2.95P
35 MobileMail 0.0% 0:12.793 5 95 175 1.69M 19.2M 1.72P 10P
34 MobilePhon 0.0% 0:06.799 2 64 169 1.32M 19.3M 0B 8.55P
28 notifyd 0.0% 0:06.798 2 147 25 212K 316K 0B 1.63P
27 PXLdaemon 0.0% 0:04.800 1 15 106 620K 1.34M 0B 3.56P
26 mediaserve 0.0% 0:30.775 14 157 175 1.29M 2.01M 117T 6.88P
25 ptpd 0.0% 0:06.798 2 47 70 428K 856K 0B 3.17P
24 update 0.0% 0:04.800 1 13 20 108K 284K 0B 1.06P
23 syslogd 0.0% 0:08.797 3 35 28 196K 340K 0B 1.63P
22 lockdownd 0.0% 0:10.795 4 53 78 592K 1.23M 312T 4.59P
21 mDNSRespon 0.0% 0:06.798 2 45 47 356K 664K 0B 3.03P
20 iapd 0.0% 0:12.793 5 85 149 904K 2.60M 0B 6.25P
19 cron 0.0% 0:04.800 1 13 42 272K 428K 0B 1.92P
18 crashrepor 0.0% 0:04.800 1 25 60 348K 520K 0B 2.19P
17 configd 0.0% 0:12.795 5 138 82 756K 1.09M 0B 6.27P
16 SpringBoar 0.0% 0:26.784 10 203 284 3.28M 20.0M 0B 86P
14 CommCenter 0.0% 0:22.783 10 88 77 740K 836K 0B 4.92P
13 BTServer 0.0% 0:12.792 5 51 72 460K 1.34M 0B 4.86P
1 launchd 0.0% 0:08.796 3 61 28 232K 360K 0B 1.73P
Processes: 21 total, 1 running, 20 sleeping... 79 threads 15:07:09
Load Avg: 0.37, 0.29, 0.12 CPU usage: 50.0% user, 50.0% sys, 0.0% idle
SharedLibs: num = 0, resident = 0B code, 0B data, 0B LinkEdit
MemRegions: num = 1809, resident = 15.2M + 0B private, 26.8M shared
PhysMem: 20.9M wired, 19.7M active, 17.4M inactive, 58.1M used, 43.4M free
VM: 171P + 0B 8734(0) pageins, 0(0) pageouts

PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
60 top 0.0% 0:04.800 1 17 46 300K 524K 0B 2.22P
55 mediaserve 0.0% 0:30.775 14 147 174 1.21M 2.01M 0B 6.23P
42 sh 0.0% 0:04.800 1 13 31 384K 1.38M 0B 4.56P
40 sshd 0.0% 0:04.801 1 14 30 328K 680K 0B 2.94P
35 MobileMail 0.0% 0:12.793 5 95 175 1.69M 19.4M 1.72P 10P
34 MobilePhon 0.0% 0:06.799 2 64 169 1.32M 19.5M 0B 8.50P
28 notifyd 0.0% 0:06.798 2 146 25 212K 316K 0B 1.63P
27 PXLdaemon 0.0% 0:04.800 1 15 106 620K 1.34M 0B 3.56P
25 ptpd 0.0% 0:06.798 2 47 70 428K 856K 0B 3.17P
24 update 0.0% 0:04.800 1 13 20 108K 284K 0B 1.06P
23 syslogd 0.0% 0:09.797 3 35 28 208K 340K 0B 1.67P
22 lockdownd 0.0% 0:10.795 4 53 78 592K 1.23M 390T 4.59P
21 mDNSRespon 0.0% 0:06.798 2 45 47 356K 664K 0B 3.03P
20 iapd 0.0% 0:12.793 5 84 149 904K 2.60M 0B 6.23P
19 cron 0.0% 0:04.800 1 13 42 272K 428K 0B 1.92P
18 crashrepor 0.0% 0:04.800 1 41 60 368K 520K 0B 2.27P
17 configd 0.0% 0:12.795 5 138 82 756K 1.09M 0B 6.27P
16 SpringBoar 0.0% 0:28.784 10 202 299 3.86M 20.3M 0B 89P
14 CommCenter 0.0% 0:22.783 10 88 77 744K 836K 0B 4.94P
13 BTServer 0.0% 0:12.792 5 53 72 464K 1.34M 0B 4.89P
1 launchd 0.0% 0:08.796 3 61 29 232K 360K 0B 1.73P

The top one is before.. the bottom one is after..

While running top when hitting "exit" in the application I saw "crashdump" flicker past for one refresh of top.. Afterward, "#TH" returned to 14 just as it had been before, (it varied while running I think it settled on 17 though), but for some reason mediaserve hung out much higher up the list in top once Funiculus had been run.. I'm not sure how top is ordering things there, but it's cpu % never seemed to read all that high (it usually read the same as the random crap you get from everything else when top runs on the iphone), but it and "top" itself always held the top two positions on the screen.. Strangely, top would sometimes say something like 5% cpu, and mediaserver would say 0%, but mediaserver would still be listed in the #1 slot.. I'm used to top defaulting to ordering by cpu %1, but that must not be the case on the iphone.

Maybe a crash is preventing some memory from being freed (shame on you bsd) and the extra memory usage is keeping the app from being able to sleep correctly? I dunno.. seems kinda strange..

Let me know if there are any other questions I can answer.. but I wouldn't put yourself out too much to fix something that really does look like a problem caused by a crusty old firmware.

-Jeff

Oh.. doh.. I think I'm an idiot.. I didn't notice the PID.. OK, it looks like mediaserve is crashing, and restarting, but maybe it's having trouble trying to connect/reconnect with services already running... So now it just bangs away forever trying to reconnect to.... whatever the hell mediaserver connects to..

-Jeff

Yeah, it crashes on mine too, so I'm not sure if that's the problem. But I'll look into it. (I never would have noticed the process id change...I tend to ignore it...good eye) It may just be a side effect of the process used to get the mic working. (I tried to run VoiceNotes and test it there, but it caused the entire phone to reboot.)

I'll make changes to the threading mechanism in a little while and see if I can get it running without using the audio system's thread...if there is a problem, and it's a 1.1.1 thing only, then I suspect that's where the problem is.

(If this were 1.0.2 thing, I might be tempted to not worry about it, but 1.1.1 is only 2 versions behind where I am, so I'll do my best to get it worked out. That, and I can't be sure it's a firmware thing, but I can't imagine any other reason at this point why you guys have problems and others don't.)

Thanks for the feedback (and debugging)...

Okay, by trial and error, I've now gotten Funiculus to exit without crashing mediaserver/itself AND without leaving a lingering thread in mediaserver. Nothing intuitive in this workaround...a seemingly random mix of stuff...
And I've changed the threading stuff...don't know whether that will have an effect or not.

It very well may have an entirely different process was running down the battery...maybe one of these CrashReporter type processes. I think the clue is in the Usage settings...this perhaps could be used to figure out whether the battery is running down without having to wait for it to do so...you can look at usage, then put it in standby for a minute or two, and check again to see if the usage goes up...I haven't tested this out yet because running Installer will blank the usage until another full recharge.

I'll try to post a sneak-preview of version 0.60 for download on this site...maybe tonight if I can get everything working somewhat ok.

Yeah I pulled a before, during, and after process list and had the same exact results as Jeff. And kind of off topic, but the only reason I haven't updated to 1.1.3 is I'm on T-Mobile and I'm just waiting until someone can actually figure out a clean way of upgrading without all the hoops to have to jump through to get basic programs working correctly. But let me know if you need more help in testing.

I'm about to make a new entry for this that contains an updated (beta) version...it actually has a lot more "stuff", but some of the stuff needs more ironing out. Check that entry for details...