Float support for --seek --jump and --info options

Submitted by kenjyco on Tue, 2017-11-21 19:38

Forums:

First of all, thanks for creating MOC! I've been a fan since coming across this project over 10 years ago when I was seeking out low-resource console/terminal tools for specific everyday tasks.

Since last year, I have mostly been interacting with the mocp server via the CLI tool. I wanted to know the possibility of having the --info option return CurrentSec as a float and the --seek and --jump options be able to accept a float.

Would be pretty awesome to have that extra bit of precision when jumping to specific points in a file.

jcf

Tue, 2017-11-21 22:06

There is an upcoming requirement for sub-second timing as a prerequiste for other developments. I have a patch on the stack for nanosecond resolution (which is major overkill but makes use of the provided data structure used elsewhere in MOC), but it doesn't currently extend to the options you mention. I'll look into doing that.

kenjyco

Fri, 2017-11-24 18:27

Yea that's awesome! Would that potentially be in the 2.6 release or a later one?

Thanks for the quick reply.

jcf

Fri, 2017-11-24 20:10

It was scheduled for MOC 2.7, but I may bring it forward. However, another change request in this area highlighted the need for some required maintenance to this code, and I'm really wanting to get MOC 2.6 out... there's still much to do and people have waited too long already.

kenjyco

Sat, 2017-11-25 16:00

I'm just glad to know the change is actually planned somewhere down the pipeline. Potentially within a year?

Getting repeat/shuffle info from CLI would be cool too :)

jcf

Sat, 2017-11-25 19:38

Each time I put out a MOC release I am fully expecting that the next release will follow it within a few months at the most. Every time I've put out a MOC release the next release has been a long time in coming.

Although I have a lot of patches waiting to be committed, anything which draws the focus of attention away from them usually means that it takes some time for me to get back to them. That interruption can be anything from waiting for someone to reply to me, to the need to address a higher priority bug, to a larger intrastructural change to the code which has been uncovered by the smaller change being worked on, and even to the need to do the mundane, real-world tasks such as mowing the lawns. A distraction of more than a few days incurs an (increasingly significant) overhead in picking up my train of thought for that work again.

I also like to group related changes together rather than having them appear intermingled with unrelated work, so a minor patch which is not concerned with the main theme I'm currently working towards committing will be delayed to a more appropriate time.

But the primary brake on the flow of commits is the time available to do it, and particularly at present the availablity of extended, uninterrupted periods of time where the sustained concerntration required to complete some tasks can be found.

So, within a year? I really don't know. But be assured that work on MOC is still ongoing, albeit that progress is at a crawl sometimes.

kenjyco

Sun, 2017-11-26 00:14

Yea that makes a lot of sense. It's especially tough when you have a bunch of stale code that hasn't been merged in and you forget the context of the changes. Or when you finally get around to doing some kind of big code refactor to make it easier to do future work, but then you may need to re-work some of the unmerged code to take advantage of the major changes.

Several days a week, I try to get up early to work on personal projects when I know I can have 2-3 hours of focused/uninterrupted time to go deep on something... before any real-world tasks for life and my actual paying job need to be addressed.

It seems that you are the primary maintainer for this project, so I want to let you know that I appreciate all of the work you are putting in to prioritize & group changes to keep MOC one of the best ways to enjoy music/podcasts.