search

csound-plugins / risset

Csound Package Manager
18 stars 0 forks source link

Enable risset to host user-defined opcodes and potentially other resources as well as plugin opcodes #3

Closed gogins closed 3 years ago

gogins commented 4 years ago

Risset should copy UDO code to a standard location, first looking at Csound's standard INCDIR environment variable, second using a standard location in the user's home directory configuration.

Name collisions should be managed by requiring the user to rename a colliding UDO or filename, and encouraging the use of a pseudo-namespace filename and UDO prefix, e.g. "my_udo" in "my_udo.csd."

gesellkammer commented 4 years ago

Yes, this is very important. As you point out, there are clear limitations in the csound language regarding the flat namespace.

Things to clear, in random order:


opcode bufRead, i, S
  /* Read a soundfile via gen1

  Args:
    Spath: the path of the soundfile

  Returns:
    itab: the table number
  */
  Spath xin
  itab ftgen 0, 0, 0, -1, Spath, 0, 0, 0
  xout itab
endop

Such a format could be parsed via risset and a markdown file could be autogenerated (the syntax can be parsed from the xin / xout declarations).

Regarding conflicts in filenames: this can be solved by including filenames inside folders. Given a folder structure

    foo/
        barudos.udo
        bazudos.udo

These could be included as


#include "foo/barudos.udo"
#include "foo/bazudos.udo"
gogins commented 4 years ago

Thanks for your response to my comments. Your proposals make sense to me. I prefer ".inc" to ".udo" because that is not limited in meaning to UDOs, for example I store whole instruments in .inc files, but I don't really care. Your suggestions are fine.

Using folders for namespace is fine for filenames, does not work for UDO names, but it is certainly a good idea.

I think it is reasonable to require the author of a UDO to provide a markdown file. Risset can no doubt be gotten to display this in a pretty format.

Thanks, Mike

Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com

On Sun, Jul 19, 2020 at 4:09 PM Eduardo Moguillansky < notifications@github.com> wrote:

Yes, this is very important. As you point out, there are clear limitations in the csound language regarding the flat namespace.

Things to clear, in random order:

  • Which is the extension of include files? .udo?
  • What to do if the system does not define INCDIR? Should risset install to a default location and prompt the user to set INCDIR? Or should csound query a default location if INCDIR is not defined and an include file is not found relative to the .csd file?
  • What should that default location be? Following the standards, something like (I'm prefixing everything with csound6 in the event that csound7 would break compatibility in some way):
    • linux: ~/.local/share/csound6/udos
    • macos: ~/Library/Application Support/csound6/udos
    • windows: C:\Documents and Settings\Application Data\csound6\udos
  • What about documentation for udos? Should each udo need a man page, similar to opcodes, in markdown format? Couldn't we make it possible to include inline documentation?

opcode bufRead, i, S / Read a soundfile via gen1 Args: Spath: the path of the soundfile Returns: itab: the table number / Spath xin itab ftgen 0, 0, 0, -1, Spath, 0, 0, 0 xout itabendop

Such a format could be parsed via risset and a markdown file could be autogenerated (the syntax can be parsed from the xin / xout declarations).

Regarding conflicts in filenames: this can be solved by including filenames inside folders. Given a folder structure

foo/
    barudos.udo
    bazudos.udo

These could be included as

include "foo/barudos.udo"#include "foo/bazudos.udo"

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/csound-plugins/risset/issues/3#issuecomment-660701099, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQIGJLASC5SOXWR27IZDUDR4NHITANCNFSM4PBM6XSQ .

gogins commented 3 years ago

The idea of Risset is good but it is not being improved or maintained.

gesellkammer commented 3 years ago

The idea behind the current design is that potential contributors would require commit rights for this repo and could add their own plugins and potentially other resources under their own folder. Since the number of such contributors is in reality very small, this seemed to be a good compromise between flexibility and simplicity (this is more/less how pd's deken works). But feedback was not very positive in this regard, requiring a design in which risset would work more like an aggregator of other repositories.

gogins commented 3 years ago

I completely agree that there is a need for a compromise between flexibility and simplicity. The problem that is getting in the way is multi-platform support. I think if you had continuous integration working in risset-data for each platform, and with built-in build recipes, then it might be possible for somebody who really only works on one platform, such as Linux or Mac OS, to contribute code that risset-data's continuous integration builds would provide for other platforms. But this already requires a certain degree of complexity and makes a number of assumptions to which there would inevitably be exceptions...

The fact that Steven Yi is still talking about a "package system" that has never been implemented indicates that there is a real need for something like this.

I'll keep watching and thinking about this.

Best, Mike

Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com

On Fri, Jan 22, 2021 at 7:37 PM Eduardo Moguillansky < notifications@github.com> wrote:

The idea behind the current design is that potential contributors would require commit rights for this repo and could add their own plugins and potentially other resources under their own folder. Since the number of such contributors is in reality very small, this seemed to be a good compromise between flexibility and simplicity (this is more/less how pd's deken works). But feedback was not very positive in this regard, requiring a design in which risset would work more like an aggregator of other repositories.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/csound-plugins/risset/issues/3#issuecomment-765800502, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQIGJLJSGSHOIJARQ6XCGDS3IK6NANCNFSM4PBM6XSQ .

gesellkammer commented 3 years ago

risset-data is just a data repository. For the csound-plugins (https://github.com/csound-plugins/csound-plugins) I have a nicely working build environment plus continuous integration for all three major desktop platforms plus a script to copy the resulting binaries and the documentation to the corresponding folder in risset-data. If anyone needs such an environment they can simply clone this repository and fill it with their own plugins or even ask for commit rights to that repository. risset and risset-data are for distribution only.

gogins commented 3 years ago

Okay, somehow I id not know about that. I'll try it out.

Thanks, Mike

On Sat, Jan 23, 2021, 01:45 Eduardo Moguillansky notifications@github.com wrote:

risset-data is just a data repository. For the csound-plugins ( https://github.com/csound-plugins/csound-plugins) I have a nicely working build environment plus continuous integration for all three major desktop platforms plus a script to copy the resulting binaries and the documentation to the corresponding folder in risset-data. If anyone needs such an environment they can simply clone this repository and fill it with their own plugins or even ask for commit rights to that repository. risset and risset-data are for distribution only.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/csound-plugins/risset/issues/3#issuecomment-765878561, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQIGJKIEG2UXZ7X3AR7D4TS3JWABANCNFSM4PBM6XSQ .