[PD] Request for help investigating the xeq sequencer package

[Fred Jan Kraan]

On 22-10-16 23:55, Jonathan Wilkes wrote:
> Hi Fred Jan,
> What features do you find in the xeq library which couldn't be sustainably
> implemented with abstractions?

What features it contains is to be found out. For a great part, they 
probably could be implemented as abstractions. The Context (v2) 
implementation by Liam Goodacre proves this is possible.

At the existing documentation is outdated and incomplete, and so is the 
list of features. Looking at the code gives only hints of features. You 
have to know about sequencer usage to interpret these hints correctly.
>
> -Jonathan
>
Fred Jan
>
> ------------------------------------------------------------------------
> *From:* Fred Jan Kraan <fjkraan at xs4all.nl>
> *To:* "pd-list at lists.iem.at" <pd-list at lists.iem.at>
> *Sent:* Friday, October 21, 2016 4:30 PM
> *Subject:* [PD] Request for help investigating the xeq sequencer package
>
> Hi All,
>
> To find out if xeq, the sequencer package created by Krzysztof Czaja in
> 2006, is worth fixing, documenting and making a reliable deken package,
> I am looking for someone knowledgeable of and interested in sequencers.
>
> Xeq is a sequencer suite inspired by the [qlist] object, but extended by
> several useful features, only very rudimentary described. At least it
> supports midi files, searching for note sequences in its dictionaries,
> and maybe even some sort of programming to control sequence parsing.
>
> At the moment, xeq compiles but because of the very limited
> documentation; an outdated paper and a few poorly documented patches its
> usage range is unknown.
>
> To some extend I can fix bugs when it is clear what the proper behaviour
> is, but my knowledge of advanced sequencer usage is too limited to find
> out how it should work. This also limits my capability to create useful
> help-patches. So I am seeking help from someone with more than average
> knowledge of sequencers.
>
> I am aware that software can be too complicated to be useful, so at one
> point the conclusion could be that xeq is not worth the effort to
> document and debug it. But so far the framework looks well structured,
> and some of the charted functionality is working very well.
>
> For testing the source is available at
> https://github.com/electrickery/pd-xeq/tree/experimentalReconstruction,
> <https://github.com/electrickery/pd-xeq/tree/experimentalReconstruction,>
> but I can provide a deken like zip with an executable and available
> documentation for all the usual platforms. No stabilility is guaranteed,
> but it sure it will be 'interesting' (if you like sequencers ;-).
>
> Fred Jan
>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>