MOC

The last month can be described as nothing less than victorious for MOC. The infamous stuttering problem which makes long-playing audio sound like a broken record under some circumstances has finally been traced to ALSA's dmix component. So the ... [More] circumvention for the ALSA stutter bug has been included in both the latest 2.5.2 maintenance and 2.6-alpha3 development releases which are now available. The other significant problem which has been resolved in both releases is the failure to build on split ncurses/tinfo systems. Perhaps the most significant new functionality in 2.6-ahlpa3 is the ability for the FFmpeg decoder to read from Internet streams. That makes all the formats and codecs the FFmpeg/LibAV libraries support able to be played from streamed audio. Other noteworthy functionality enchancements are: 24-bit support has been added to the OSS sound driver. All formats provided by Sndfile are now supported. The DSD formats are now supported via FFmpeg/LibAV. As always, check the distribution NEWS file for a more complete summary and the SVN log for the full details. [Less]

The last month can be described as nothing less than victorious for MOC. The infamous stuttering problem which makes long-playing audio sound like a broken record under some circumstances has finally been traced to ALSA's dmix component. So the ... [More] circumvention for the ALSA stutter bug has been included in both the latest 2.5.2 maintenance and 2.6-alpha3 development releases which are now available. The other significant problem which has been resolved in both releases is the failure to build on split ncurses/tinfo systems. Perhaps the most significant new functionality in 2.6-alpha3 is the ability for the FFmpeg decoder to read from Internet streams. That makes all the formats and codecs the FFmpeg/LibAV libraries support able to be played from streamed audio. Other noteworthy functionality enchancements are: 24-bit support has been added to the OSS sound driver. All formats provided by Sndfile are now supported. The DSD formats are now supported via FFmpeg/LibAV. As always, check the distribution NEWS file for a more complete summary and the SVN log for the full details. [Less]

Most MOC users have not heard much from the top floor of MOC Corporate Headquarters during the past eighteen months. There were some activities planned for 2015 which would have taken the focus off MOC development for a month or two, but as things ... [More] unfolded it turned out to be an annus horribilis -- a truely terrible year in which even those planned activities had to be sacrificed. However, development is underway again and today we have two release announcements to make. The less significant of these announcements is that MOC 2.5.1 has now hit the shelves. This is maintenance release so there're no new features in it but a handful of bug fixes (and the term "bug" is used fairly loosely here). Perhaps the most significant of these is the adaption to the FFmpeg 3.0 API and the fixing of some build errors on *BSD systems. Of much more significance is the release of MOC 2.6-alpha2. This release repositions MOC as being compliant with the C99 (ISO/IEC 9899:1999) and POSIX.1-2001 (IEEE 1003.1:2001 or ISO 9945:2002) standards. Although this means MOC should now be able to build and run on any platform having a C99 capable compiler and a POSIX.1-2001 compatible system (and much work has gone into try and ensure it does), there is some confusion in the interpretation of the standards between (and even within) various platforms and there may be non-compliant code which has been overlooked, so at this time standards compliance should be regarded as being aspirational rather than accomplished. It is important that those who are able to build from source on their own platforms do so and report any build problems they encounter; that's the only way to move closer to the fully standards compliant goal. In addition, other 2.6-alpha2 highlights include: compiler warnings new in GCC-5 and 6 have been addressed, mono-mixing and softmixing now work independantly, VQF and TTA formats are now supported (via FFmpeg/LibAV), MOC now uses POPT for command line parsing (see the mocp manpage for details) and in-memory circular logging is now available for long-running MOC sessions. As always, the respective NEWS files contain a more detailed summary of the changes in the two releases, and the SVN commit log will reveal every single change in much more detail than most will want to know. So, where to now? The main theme of MOC 2.6 is the integration of user-contributed patches. Already work on 2.6-alpha3 is well advanced and includes several long-awaited features, so it should not be as long a wait for this release. And finally a small service announcement: a reminder that MOC's SVN is now at svn://svn.daper.net/moc [Less]

Most MOC users have not heard much from the top floor of MOC Corporate Headquarters during the past eighteen months. There were some activities planned for 2015 which would have taken the focus off MOC development for a month or two, but as things ... [More] unfolded it turned out to be an annus horribilis -- a truely terrible year in which even those planned activities had to be sacrificed. However, development is underway again and today we have two release announcements to make. The less significant of these announcements is that MOC 2.5.1 has now hit the shelves. This is maintenance release so there're no new features in it but a handful of bug fixes (and the term "bug" is used fairly loosely here). Perhaps the most significant of these is the adaption to the FFmpeg 3.0 API and the fixing of some build errors on *BSD systems. Of much more significance is the release of MOC 2.6-alpha2. This release repositions MOC as being compliant with the C99 (ISO/IEC 9899:1999) and POSIX.1-2001 (IEEE 1003.1:2001 or ISO 9945:2002) standards. Although this means MOC should now be able to build and run on any platform having a C99 capable compiler and a POSIX.1-2001 compatible system (and much work has gone into try and ensure it does), there is some confusion in the interpretation of the standards between (and even within) various platforms and there may be non-compliant code which has been overlooked, so at this time standards compliance should be regarded as being aspirational rather than accomplished. It is important that those who are able to build from source on their own platforms do so and report any build problems they encounter; that's the only way to move closer to the fully standards compliant goal. In addition, other 2.6-alpha2 highlights include: compiler warnings new in GCC-5 and 6 have been addressed, mono-mixing and softmixing now work independantly, VQF and TTA formats are now supported (via FFmpeg/LibAV), MOC now uses POPT for command line parsing (see the mocp manpage for details) and in-memory circular logging is now available for long-running MOC sessions. As always, the respective NEWS files contain a more detailed summary of the changes in the two releases, and the SVN commit log will reveal every single change in much more detail than most will want to know. So, where to now? The main theme of MOC 2.6 is the integration of user-contributed patches. Already work on 2.6-alpha3 is well advanced and includes several long-awaited features, so it should not be as long a wait for this release. And finally a small service announcement: a reminder that MOC's SVN is now at svn://svn.daper.net/moc [Less]

I've been working recently on bringing MOC up to the currently common C99 and POSIX.1-2001 standards. However, the road block I keep running into is with OpenBSD... do we continue to support it? Targetting these standards will enable the removal of ... [More] some fallback code for some POSIX-mandated functions, and the use of more modern code contructs. But perhaps more importantly, it should remove the need to support specific OSs and allow MOC to be used on any standards-compliant UNIX-like system (although there remain some GNU-specific constructs which will be addressed later). According to the OpenBSD sys/unistd.h header, the version of the POSIX.1 standard it targets for compliance is the 1990 one. Whatever their reasons, that standard's nearly a quarter of a century old now, so maybe in the interests of moving MOC forward we have to leave OpenBSD behind on MOC 2.5. For those who are using MOC on OpenBSD (and I honestly don't know if there is anyone), I see a number of alternatives: Stop using MOC, Remain behind on MOC 2.5, Move away from OpenBSD (probably to FreeBSD or NetBSD, both of which target the 2001 standard), Convince the OpenBSD developers to move to the more recent POSIX standard, Convince OpenBSD's MOC package maintainer (if there still is one) to provide and maintain within the OpenBSD distribution the patches necessary to downgrade MOC to the 1990 standard, Patch MOC yourself to downgrade it to that standard, or Have someone fork MOC for OpenBSD. None of those options is good news for any OpenBSD user still roaming free in MOCland, so I'd be interested in your feedback. If I hear nothing within a week, I'll consider it acceptable to require POSIX.1-2001 compliance and continue moving forward. John Fitzgerald, MOC Maintainer. [Less]

I've been working recently on bringing MOC up to the currently common C99 and POSIX.1-2001 standards. However, the road block I keep running into is with OpenBSD... do we continue to support it? read more

I've been working recently on bringing MOC up to the currently common C99 and POSIX.1-2001 standards. However, the road block I keep running into is with OpenBSD... do we continue to support it? Targetting these standards will enable the removal of ... [More] some fallback code for some POSIX-mandated functions, and the use of more modern code contructs. But perhaps more importantly, it should remove the need to support specific OSs and allow MOC to be used on any standards-compliant UNIX-like system (although there remain some GNU-specific constructs which will be addressed later). According to the OpenBSD sys/unistd.h header, the version of the POSIX.1 standard it targets for compliance is the 1990 one. Whatever their reasons, that standard's nearly a quarter of a century old now, so maybe in the interests of moving MOC forward we have to leave OpenBSD behind on MOC 2.5. For those who are using MOC on OpenBSD (and I honestly don't know if there is anyone), I see a number of alternatives: Stop using MOC, Remain behind on MOC 2.5, Move away from OpenBSD (probably to FreeBSD or NetBSD, both of which target the 2001 standard), Convince the OpenBSD developers to move to the more recent POSIX standard, Convince OpenBSD's MOC package maintainer (if there still is one) to provide and maintain within the OpenBSD distribution the patches necessary to downgrade MOC to the 1990 standard, Patch MOC yourself to downgrade it to that standard, or Have someone fork MOC for OpenBSD. None of those options is good news for any OpenBSD user still roaming free in MOCland, so I'd be interested in your feedback. If I hear nothing within a week, I'll consider it acceptable to require POSIX.1-2001 compliance and continue moving forward. John Fitzgerald, MOC Maintainer. [Less]

Happy Tenth Anniversary, MOC! Yes, folks, MOC is ten years old today. Well, it's the tenth anniversary of the first commit into SVN anyway, but the first official release of MOC which I can find predates that by some two years. With MOC 2.5.0 finally ... [More] having been released and MOC 2.6 now underway, it seems like a good time to take a look back at where we've been and a look forwards to let people know how I see MOC development unfolding from here. Looking Back MOC 2.5.0 "Consolidation" was a very long time in the making. It was a transitional release and drew a line in the sand between Damian's development of MOC and my own maintainership of it. For some time prior to my taking up the role of MOC Maintainer, Damian had not been able to devote the time required to keep MOC moving forward. He had new work and family commitments, and MOC had become a lesser part of his life. So MOC was beginning to suffer through lack of maintainance. My involvement with MOC began late in 2008. I wanted to use MOC to do console-based rough audio editting. That involved some work in MOC to provide the mechanisms I needed to support that primary functionality. It was completed and I have been using it for over five years now. But it still hasn't made it into the MOC codebase because if it is to be released publicly there is more work required to generalise it and provide a seemless and consistant interface. I'm still working towards that goal. Damian asked me if I wanted to take over the maintainance of MOC. I was reluctant to do so because of being unable to meet the time commitment involved. However, over the next few months I ended up falling into the role anyway as I got further and further into integrating my new functionality and became more and more familiar with the codebase. I soon realised that my work could be broken down into a number of stages, and rather than just adding mechanisms in a somewhat ad hoc manner it would be better to turn those stages into new MOC releases with each release bringing in more of the mechanisms required to support my end goal. It was also necessary to provide as clean a codebase as possible from which future development could proceed, and so the focus shifted to historical bugs and backlogged user requests. This was largely successful, but there are still a small number of bugs remaining which are either benign and rarely encountered or for which the cause could not be identified in the time available. There are also a small number of user requests remaining which I either haven't had time to address or which have been deliberately held over awaiting the support mechanisms which would make their implementation easier, cleaner or redundant. Apart from the ever-present constraint of my own time availablity, pursuing bugs and addressing requests usually involved the co-operation of the original reporter or requester and I was also constrained by their availablity. It was more usually the case than not that I could not reproduce the bug myself and so was left with no choice but to debug remotely by e-mail... and that is a very time-consuming process. Looking Forward Now that the line in the sand has been drawn, my focus will change from historical bug fixing to new development. There will be some changes which I hope will allow me to do that and move MOC forward more quickly than in the past. And they involve you, the MOC user community. I will be disinclined to investigate bugs for which insufficient information is provided in the first instance. If you don't provide the basic information needed to begin debugging your report is likely to be ignored; at least, it is likely to be ignored by me. I am hoping that people in the MOC community who are familiar with the particular circumstances and/or environment surrounding a bug report will step forward and either debug the problem or at least triage it to the point where I can be presented with a workable bug report. I would also like someone to volunteer to act as a co-ordinator for such triage work. And if you do submit a bug report be prepared to engage with such a co-ordinator or mocmaint in the debugging process if necessary. You can choose to submit it at a time when you will be available to pursue it; mocmaint has no such choice. Users who report bugs and do nothing more or who abandon the debugging effort part way through take time away from more productive efforts. The aim of the changes outlined in the last three paragraphs are to minimise the distractions of engaging in prolonged e-mail discussions in order to extract the most basic of information. There are also some other contributions the MOC community can make to help me keep focused on development. I will not be testing new commits as thoroughly as I have in the past. In the past, I have imposed heavily on those few people who have generously given of their time to assist by sending out pre-commit patches in an effort to ensure they work on a variety of platforms. Because most commits will now be driven by new development, as long as they build and pass testing on my system I will be committing them and relying on the MOC community to field test them. If you wish to help with this then you should be technically competant enough to do it without significant input from me and be able to report any issues and suggestions comprehensively and directly to mocmaint. And obviously you will need to track the current SVN HEAD closely. There are some aspects of MOC which I cannot support effectively myself, and on which I have often been working blind and for which I have been reliant on the goodwill of others to review and test my work. There is a risk that these areas will be left behind or be unintentionally broken by surrounding changes as MOC moves forward and so become unsupported. Technical users of the MOC community might like to adopt one or more of these areas for which they have the capability to support. These areas are: non-Linux platforms, non-Slackware distributions, non-64-bit machines, Internet streams, X-Windows compatibility, Unicode and non-ASCII character sets, TiMidity, Jack, OSS and SNDIO. There are other less specific areas for which I just do not have the time to support to the level I would like to see them supported. These areas include: the marshalling and maintainance of contributions, trawling the Forum posting for forgotten, uncompleted or fixed but unclosed issues, indexing of the topics of Forum posts, occasional technical research tasks, and the development of more complete documentation (particulary from the user's point of view). Without people offering to undertake this work it is unlikely ever to be done. If you wish to contribute code then you're welcome to do so, but it is strongly advised that you discuss your plans with mocmaint first so that duplicated effort and clashes with other development work can be avoided. Your contribution should be compatible with MOC, both in terms of overall purpose and in being consistant with MOC coding style. Review existing code and previous commits to learn what mocmaint expects. Ensure that your contribution is functionally complete and well tested. When making a contribution you should plan to stand by it, at least for a while. You should monitor the Forum and be prepared to respond to suggestions and bug reports which relate to your contribution unprompted by mocmaint. Those who have already contributed patches but have not yet had them committed should expect to be contacted regarding them shortly. Please ensure that your patches are up to date and conform to the expectations summarised above. If you haven't heard anything within a few months then please prompt mocmaint to ensure that your contribution hasn't been overlooked. The Roadmap So what are my plans for future MOC development? Until MOC 2.5.0 was released, I kept my plans for future developments pretty quiet. But it's now appropriate that I make them public. The further into future we're looking, the less well developed and changable is the plan. Much of the design work for MOC 2.6 is done and some of it is already coded and ready to be tested; by contrast, the intentions of MOC 3.0 are quite vague and fluid. MOC 2.6 "Usability": There are five areas which it is intended to address in this release: committing the contributed patches outstanding; fulfilling some of the feature request backlog; making MOC more usable, flexible and functional; providing additional mechanisms to support future developments; and ongoing code cleaning, polishing, tightening and upgrading. MOC 2.7 "Plug-Ins": An overhaul of the existing plug-in architecture is planned which will enable some of the existing functionality to be moved into plug-ins. Plug-ins should be able to be supplied and maintained by third parties independently of the core MOC codebase which can extend the functionality of MOC in areas such as tag management, audio effects, playlists and cue sheets. MOC 2.8 "Scripting": Client-side scripting is the feature for which I started working on MOC in support of rough audio editting. Many of the feature requests which have arisen over the last few years have helped to refine the requirements of the scripting interface in MOC, and it is my intention that anything which can be done manually at the client can be also be done from within a script. MOC 2.9 "Interfaces": Allowing MOC to co-operate with other applications using standard protocols is the aim of this release. In particular, I would like any MPD client to also be able to drive MOC. MOC 3.0 "New Era": Possibilites include a C++ rewrite and/or a move to aspect-oriented programming. It would also be a good point at which to move MOC to a Git repository. As with all plans, these are subject to change; they've changed already as ideas have crystallised and mechanisms become generalised. In particular, there is much work to be done in MOC 2.6 and it's quite possible that it may be split into two or more releases as various aspects of it reach completion and it seems appropriate to have them form a distinct release. In that case, the subsequent releases will be renumbered accordingly. John Fitzgerald, MOC Maintainer. [Less]

Happy Tenth Anniversary, MOC! Yes, folks, MOC is ten years old today. Well, it's the tenth anniversary of the first commit into SVN anyway, but the first official release of MOC which I can find predates that by some two years. With MOC 2.5.0 ... [More] finally having been released and MOC 2.6 now underway, it seems like a good time to take a look back at where we've been and a look forwards to let people know how I see MOC development unfolding from here. Looking Back MOC 2.5.0 "Consolidation" was a very long time in the making. It was a transitional release and drew a line in the sand between Damian's development of MOC and my own maintainership of it. For some time prior to my taking up the role of MOC Maintainer, Damian had not been able to devote the time required to keep MOC moving forward. He had new work and family commitments, and MOC had become a lesser part of his life. So MOC was beginning to suffer through lack of maintainance. My involvement with MOC began late in 2008. I wanted to use MOC to do console-based rough audio editting. That involved some work in MOC to provide the mechanisms I needed to support that primary functionality. It was completed and I have been using it for over five years now. But it still hasn't made it into the MOC codebase because if it is to be released publicly there is more work required to generalise it and provide a seemless and consistant interface. I'm still working towards that goal. Damian asked me if I wanted to take over the maintainance of MOC. I was reluctant to do so because of being unable to meet the time commitment involved. However, over the next few months I ended up falling into the role anyway as I got further and further into integrating my new functionality and became more and more familiar with the codebase. I soon realised that my work could be broken down into a number of stages, and rather than just adding mechanisms in a somewhat ad hoc manner it would be better to turn those stages into new MOC releases with each release bringing in more of the mechanisms required to support my end goal. It was also necessary to provide as clean a codebase as possible from which future development could proceed, and so the focus shifted to historical bugs and backlogged user requests. This was largely successful, but there are still a small number of bugs remaining which are either benign and rarely encountered or for which the cause could not be identified in the time available. There are also a small number of user requests remaining which I either haven't had time to address or which have been deliberately held over awaiting the support mechanisms which would make their implementation easier, cleaner or redundant. Apart from the ever-present constraint of my own time availablity, pursuing bugs and addressing requests usually involved the co-operation of the original reporter or requester and I was also constrained by their availablity. It was more usually the case than not that I could not reproduce the bug myself and so was left with no choice but to debug remotely by e-mail... and that is a very time-consuming process. Looking Forward Now that the line in the sand has been drawn, my focus will change from historical bug fixing to new development. There will be some changes which I hope will allow me to do that and move MOC forward more quickly than in the past. And they involve you, the MOC user community. I will be disinclined to investigate bugs for which insufficient information is provided in the first instance. If you don't provide the basic information needed to begin debugging your report is likely to be ignored; at least, it is likely to be ignored by me. I am hoping that people in the MOC community who are familiar with the particular circumstances and/or environment surrounding a bug report will step forward and either debug the problem or at least triage it to the point where I can be presented with a workable bug report. I would also like someone to volunteer to act as a co-ordinator for such triage work. And if you do submit a bug report be prepared to engage with such a co-ordinator or mocmaint in the debugging process if necessary. You can choose to submit it at a time when you will be available to pursue it; mocmaint has no such choice. Users who report bugs and do nothing more or who abandon the debugging effort part way through take time away from more productive efforts. The aim of the changes outlined in the last three paragraphs are to minimise the distractions of engaging in prolonged e-mail discussions in order to extract the most basic of information. There are also some other contributions the MOC community can make to help me keep focused on development. I will not be testing new commits as thoroughly as I have in the past. In the past, I have imposed heavily on those few people who have generously given of their time to assist by sending out pre-commit patches in an effort to ensure they work on a variety of platforms. Because most commits will now be driven by new development, as long as they build and pass testing on my system I will be committing them and relying on the MOC community to field test them. If you wish to help with this then you should be technically competant enough to do it without significant input from me and be able to report any issues and suggestions comprehensively and directly to mocmaint. And obviously you will need to track the current SVN HEAD closely. There are some aspects of MOC which I cannot support effectively myself, and on which I have often been working blind and for which I have been reliant on the goodwill of others to review and test my work. There is a risk that these areas will be left behind or be unintentionally broken by surrounding changes as MOC moves forward and so become unsupported. Technical users of the MOC community might like to adopt one or more of these areas for which they have the capability to support. These areas are: non-Linux platforms, non-Slackware distributions, non-64-bit machines, Internet streams, X-Windows compatibility, Unicode and non-ASCII character sets, TiMidity, Jack, OSS and SNDIO. There are other less specific areas for which I just do not have the time to support to the level I would like to see them supported. These areas include: the marshalling and maintainance of contributions, trawling the Forum posting for forgotten, uncompleted or fixed but unclosed issues, indexing of the topics of Forum posts, occasional technical research tasks, and the development of more complete documentation (particulary from the user's point of view). Without people offering to undertake this work it is unlikely ever to be done. If you wish to contribute code then you're welcome to do so, but it is strongly advised that you discuss your plans with mocmaint first so that duplicated effort and clashes with other development work can be avoided. Your contribution should be compatible with MOC, both in terms of overall purpose and in being consistant with MOC coding style. Review existing code and previous commits to learn what mocmaint expects. Ensure that your contribution is functionally complete and well tested. When making a contribution you should plan to stand by it, at least for a while. You should monitor the Forum and be prepared to respond to suggestions and bug reports which relate to your contribution unprompted by mocmaint. Those who have already contributed patches but have not yet had them committed should expect to be contacted regarding them shortly. Please ensure that your patches are up to date and conform to the expectations summarised above. If you haven't heard anything within a few months then please prompt mocmaint to ensure that your contribution hasn't been overlooked. The Roadmap So what are my plans for future MOC development? Until MOC 2.5.0 was released, I kept my plans for future developments pretty quiet. But it's now appropriate that I make them public. The further into future we're looking, the less well developed and changable is the plan. Much of the design work for MOC 2.6 is done and some of it is already coded and ready to be tested; by contrast, the intentions of MOC 3.0 are quite vague and fluid. MOC 2.6 "Usability": There are five areas which it is intended to address in this release: committing the contributed patches outstanding; fulfilling some of the feature request backlog; making MOC more usable, flexible and functional; providing additional mechanisms to support future developments; and ongoing code cleaning, polishing, tightening and upgrading. MOC 2.7 "Plug-Ins": An overhaul of the existing plug-in architecture is planned which will enable some of the existing functionality to be moved into plug-ins. Plug-ins should be able to be supplied and maintained by third parties independently of the core MOC codebase which can extend the functionality of MOC in areas such as tag management, audio effects, playlists and cue sheets. MOC 2.8 "Scripting": Client-side scripting is the feature for which I started working on MOC in support of rough audio editting. Many of the feature requests which have arisen over the last few years have helped to refine the requirements of the scripting interface in MOC, and it is my intention that anything which can be done manually at the client can be also be done from within a script. MOC 2.9 "Interfaces": Allowing MOC to co-operate with other applications using standard protocols is the aim of this release. In particular, I would like any MPD client to also be able to drive MOC. MOC 3.0 "New Era": Possibilites include a C++ rewrite and/or a move to aspect-oriented programming. It would also be a good point at which to move MOC to a Git repository. As with all plans, these are subject to change; they've changed already as ideas have crystallised and mechanisms become generalised. In particular, there is much work to be done in MOC 2.6 and it's quite possible that it may be split into two or more releases as various aspects of it reach completion and it seems appropriate to have them form a distinct release. In that case, the subsequent releases will be renumbered accordingly. John Fitzgerald, MOC Maintainer. [Less]

Happy Tenth Anniversary, MOC! Yes, folks, MOC is ten years old today. Well, it's the tenth anniversary of the first commit into SVN anyway, but the first official release of MOC which I can find predates that by some two years. With MOC 2.5.0 finally ... [More] having been released and MOC 2.6 now underway, it seems like a good time to take a look back at where we've been and a look forwards to let people know how I see MOC development unfolding from here. read more [Less]