-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how to obtain s7.c? #5
Comments
@umlaeute There is now https://salsa.debian.org/scheme-team. Would you be willing to package s7 and s4pd under this team? The s7 upstream repo is here: https://cm-gitlab.stanford.edu/bil/s7 Iain knows better about the rest. |
@lassik i typically use the multimedia-team to package Pd stuff. snd is also packaged there - so i'm not really a bearded schemer (well, i'm bearded, but not lisping) so i don't know how well i would fit into the scheme-team 😋 - apart from that i'm of course happy to join whatever team (and it might be nice to have a single s7 package that other packages could use; i don't know how feasible this actually is) |
If you want to package s4pd in multimedia-team, sounds like it makes a lot of sense. I've been meaning to package s7 in scheme-team. I can do it sooner if you need the s7 package. s4pd would be an excellent test case that it's working properly. Assuming s4pd can use the upstream version of s7 as-is. s7's author is very active, and quite amenable to making useful changes, so ideally we could upstream any new features that s4pd needs, but Iain is of course the ultimate judge on that. |
that sounds like a good plan. i'm currently in no hurry about the packaging timeline. |
Great. Feel free to email me (and/or the scheme-team mailing list) at any time if something relevant comes up. The snd package currently contains an embedded copy of |
My intention is to make sure I can always run Bill's latest s7, but in this rough first cut, I'm not doing so. I think I should probably plan on updating s7 with every actual release until I have a regression suite that I can run on all platforms easily. Does that sound reasonable? I'll make a ticket to myself to update to latest s7 prior to make a real 0.1 release of this. There are no modifications to s7 and I'm hoping to keep it that way. So far I've been able to just add to it on a scheme level (which is what the s74.scm file is) Putting in a new s7 should be as simple as replacing s7.c and s7.h, and rebuilding. Bill maintains it as those two files and typically puts out new versions with his updates of snd. I agree with packaging with whatever Pd does, so multi-media makes sense to me. thanks fellows! |
Yes, sounds reasonable! s74 is a nice pun :) |
Has s7 settled on a version numbering scheme yet? Something like YYYYMM or YYYYMMDD date, or the standard |
I tried the all-numbers dates, but kept inadvertently switching between month-day and day-month. The s7 version number changes when there's some API change, or some non-backwards-compatible scheme-level change (which almost never happens). I stopped making the monthly s7 tarball because it was an administrative burden and as far as I could see no-one was using it. I would just use whatever the current cm-gitlab version is, or the ccrma-ftp tarball. (Right at the moment, due to ccrma's upgrade to fedora 34, I can't update the gitlab s7 code). |
Thanks Bill, I think I'll just resync on every real release then and/or significant change to s7. Once I've figured out Pd packaging I'll do a proper (non-rc) release and update to latest s7. |
this is merely a question (with my Debian maintainer's hat on; i'd like to get s4pd into Debian)
the
s7
implementation consists of about 100000 LOC, crammed into two source files.afaict, the files found here are a copy of another s7 implementation (probably from
snd
).the questions are all related and in now particular order:
The text was updated successfully, but these errors were encountered: