Bug#603175: pd-osc (was Re: Bug#603175: reorganize upstream first)

[Hans-Christoph Steiner <hans@eds.org>]

These clearly make sense as standalone libs:

osc
net
cmos
oscillators
tabletools
str

But which, binfile, and midifile might be better in some kind of  
library.  Like perhaps some kind of 'file' library for binfile and  
midifile, that lib could include a whole suite of objects to read  
differernt files. Or maybe midifile belongs in a midi lib, which seems  
kind of like iemguts, as so on and so forth...

.hc


On Jun 14, 2011, at 12:38 PM, Martin wrote:

> Hi IOhannes,
>
> Yes go ahead. I've been wanting to do that as well. The name  
> 'mrpeach' is not very useful.
>
> Martin
>
>
> On 14/06/11 09:37 AM, IOhannes m zmoelnig wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > hi martin,
> >
> > in the process of getting numerous pd-libraries into debian (and thus
> > ubuntu and other debian derivatives), we stumbled upon a small  
> > issue in
> > your set of objects.
> >
> > as things are right now, there are no "upstream releases" of your
> > libraries; in SVN they are organized (as you are well aware) into a
> > mrpeach/ folder with various task-specific sub-folders.
> > historically, Pd-extended used the mrpeach/ folder as an  
> > organizational
> > unit. (install everything you created into a flat extra/mrpeach/  
> > folder)
> >
> > however, since your libraries don't have anything in common apart  
> > from
> > you as the author, i would prefer to package them into separate
> > packages, according to the tasks they are associated with (at least
> > those where there i a notion of 'library' as is the case with your  
> > net-,
> > osc-, cmos- objects, so people can install "pd-osc" if they need OSC
> > communication (and don't need your net/ implementation, as they  
> > intend
> > to send OSC over serial/slip).
> >
> > the rough idea is to have packages for
> > - - OSC
> > - - net
> > - - cmos
> > - - midifile
> > - - binfile
> > - - slip
> > - - str
> > - - oscillators
> > - - tabletools
> > - - which
> >
> > the debian packages would be named accordingly, with "pd-"  
> > prepended (or
> > "pd-mrpeach-" for generic names like "tabletools" and  
> > "oscillators", in
> > order to distinguish them from other libraries that could claim those
> > generic names with equal rights)
> >
> > eventually i'm planning to have a "pd-mrpeach" meta-package that  
> > would
> > depend on all these sub-packages and provide a compatibility layer  
> > for
> > older (pd-extended) patches.
> >
> > nothing is required from you to actually _do_ (e.g. code-wise), but  
> > as
> > hans has correctly pointed out, it would be good to know your  
> > feelings
> > about all this.
> >
> > cheers
> > fgamsdr
> > IOhannes
> >
> >
> >
> >
> >
> > On 2011-06-13 17:26, Hans-Christoph Steiner wrote:
> > > Tags: upstream
> > >
> > > Since there is no distinct pd-osc upstream, there are no separate
> > > releases from the upstream author only svn, and the only circulating
> > > release is the is the 'mrpeach' library included in Pd-extended, I  
> > > think
> > > we need to first get this stuff organized upstream before  
> > > uploading a
> > > package to Debian.  Have you talked with Martin Peach about it?  I  
> > > think
> > > it makes sense to have pd-osc, but I think the upstream author  
> > > should
> > > determine how the code is released.  The 'mrpeach' thing could be
> > > dropped, for example, if Martin wants it that way.
> > >
> > > .hc
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk33ZAEACgkQkX2Xpv6ydvSN8ACeOL5AKdtccX+xl5Q0xrkoGHnt
> > QmAAnR1TlHVcbqkaf3DqFdXL2Qsvpm7r
> > =Wwm4
> > -----END PGP SIGNATURE-----



----------------------------------------------------------------------------

Looking at things from a more basic level, you can come up with a more  
direct solution... It may sound small in theory, but it in practice,  
it can change entire economies.     - Amy Smith