Topics:

1. FFT infrastructure
   • See Dan's "FFT2" rewrite for part of the story (Dan)
     • Outcomes: Dan to commit the demand-rate FFT "unpacking" ugens. Dan to commit the reworked FFT ugen once he has written an accompanying IFFT.
2. Help system
   • See Scott/Dan/Marije's discussion and Dan's help browser, for part of the story (Dan)
     • Outcomes: Dan's help browser may be part of the solution, but probably more work needed. OK to commit it but keep the categories out of the main class files (put them in a separate class-extensions folder).
3. Crossplatform HID
   • See the workshop with this topic. There are several issues and I think there is a crossplatform solution needed (Marije)
     • Outcomes: Consensus that Marije's approach is good and should be used. Marije pointed out that the HID standard is inconsistent. It was suggested to implement a consistent subset and leave the rest to the future / the user. (((More detail, anyone?)))
     • Pointers have to be made to GeneralHID in HIDDeviceService and LID to get users to use the abstraction. The main thing which may change in the near future is the slot numbering and element numbering, to ensure cross platform conformity. On the long term, I will look into other solutions, which may include changing/adding primitive code.
4. How to manage / kill recent bugs.
   • glitchy sound, should there be a stable bug report page? Also, a lack of a James McC level of knowledge about the low level workings of SC. How can more devs gain this knowledge? (Josh)
     • Outcomes: sourceforge bug tracker system to be used; will try to get new reports copied to the sc-devel list. Tracker will be used to connect specific targeted bugs to point releases of SC (see below).
     • Glitchy sound was discussed. Dan had found it happening earlier that day, in a way that seemed to confirm that it was due to memory paging: it would recur if he quit SC, ran some memory-hungry apps, then restart SC; but would not recur without running the other apps imbetween. "Heater" functions were discussed (as has been discussed on-list) but AFAIK no definitive solution was agreed.
5. Stable Numbered releases.
   • A perennial favourite, but might be worth revisiting. This could reduce a bit of pressure in terms of bacwards compatibility, as with a proper changelog, people could make necessary adjustments before upgrading. (Scott)
     • Outcomes: SC 3.1 to be released later this year (Oct 31st); SC 3.2 to be released to coincide with the SC book. Changelogs to be incorporated into releases, based on data from the bug tracker and from SVN logs. Changelog file added to SVN.
     • Note: as discussed in a feature request, SourceForge requires source-code bundles to be added to the file-release area. We should do this when we release 3.1.
     • For versions 3.1 and 3.2 to look through the class library what can be included / excluded. Simplified version of JITLib to be included. A folder to be added for inactive libraries that can be accessed via quark scheme.
6. How to manage crossplatform issues.
   • This was easy when there were just one or two developers contributing to Linux and Windows ports. Now, with more people involved (also a large number on OSX), perhaps some formal means for dealing with this should be devised. (Scott)
     • Outcomes: proposed changes that possibly affect cross platform should be discussed on the dev-list, with a clear indication in the topic title (such as [cross-platform]). These items are usually proposals which in their solution rely on platform dependent code (such as use native Cocoa stuff or other OS specific primitives).
7. Pattern termination
   • Julian Rohrhuber: the problem is not Pmono only - it is the whole set of group / bus managing patterns which are a very good abstraction, I think. There is another solution than to call nil on the streams (pass in signals upstream), but when this was last discussed, the current solution was chosen.
     • Outcomes: The termination should not be done by passing in nil, but by an inevent that carries a termination flag. Streams that need termination should pass down events that contain other events that specify what is to be done.
8. Pattern arguments
   • Julian Rohrhuber: should patterns embed all arguments into the stream => all arguments can be patterns?
     • Outcomes: yes, the stream functionality that has been supported so far, should not be supported, since it is noncompliant.
9. More CmdPeriod-like functionality
   • Julian Rohrhuber and Scott Wilson: We've been having a discussion about extending the StartUp and CmdPeriod type functionality to allow for things to be executed at other times, such as after boot (this could replace Server:tree) and shut down.
     • Outcomes: Agreement that cmd-. should be customizable, but a panic button should always exist. So cmd-shift-period or cmd alt period could be alternative functionalities. cmd-shift-k for clear post window should be extended by some less risky key combination.
10. Location of writable files
    • During discussion of a bug report the problem emerged that SuperCollider writing data to its app directory ('synthdefs' and 'recordings') can cause problems for (e.g.) system-wide installs by university admins, since unprivileged users can't then write to the expected location. It was proposed to change these write paths to inside the userAppSupportDir.
      • Outcomes: I (Dan) can't remember if there was consensus on this or not. Discuss on dev list?
11. External UGens

    • Outcomes: (Marije) will make a SConstruct template for external UGens, which UGen writers and publishers can include to ease compilation for Linux.
12. Primitive plugins

    • Outcomes: JmC agrees it is a good idea, but difficult to implement.
13. Document

    • Outcomes: Cocoa specific primitives should be put in a subclass CocoaDocument in the Platform folder. CocoaDocument should then override Document like ScelDocument does. This will cause less overrides during Linux/Windows startup. We need to check what the status of Document is on Windows. In general there are still quite some classes which refer to Cocoa-specific primitives. This should be sorted out properly (caveat: for some primitives the cross-platform functionality is part of the C source code).