The Trunk: Tools-mt.685.mcz

Marcel Taeumel uploaded a new version of Tools to project The Trunk:
http://source.squeak.org/trunk/Tools-mt.685.mcz

==================== Summary ====================

Name: Tools-mt.685
Author: mt
Time: 6 April 2016, 6:11:52.977125 pm
UUID: 87ada98c-1487-8b40-aff3-51e64dd6686f
Ancestors: Tools-mt.684

Removes 'the Sound Player' as a well-known global process to get rid of some global state considering the playing of sounds. Scores, for example, are played as one process per score. Maybe sounds could benefit from that, too. Anyway, it's primarily about the global state here.

And: Sound player processes got a clear description now. So, this is no step back in usability.

=============== Diff against Tools-mt.684 ===============

Item was changed:
  ----- Method: ProcessBrowser class>>registerWellKnownProcesses (in category 'class initialization') -----
  registerWellKnownProcesses
  "Associate each well-known process with a nickname and two flags: allow-stop, and allow-debug.
  Additional processes may be added to this list as required"
 
  WellKnownProcesses := OrderedCollection new.
  self registerWellKnownProcess: []
  label: 'no process'
  allowStop: false
  allowDebug: false.
  self registerWellKnownProcess: [Smalltalk lowSpaceWatcherProcess]
  label: 'the low space watcher'
  allowStop: false
  allowDebug: false.
  self registerWellKnownProcess: [WeakArray runningFinalizationProcess]
  label: 'the WeakArray finalization process'
  allowStop: false
  allowDebug: false.
  self registerWellKnownProcess: [Processor activeProcess]
  label: 'the UI process'
  allowStop: false
  allowDebug: true.
  self registerWellKnownProcess: [Processor backgroundProcess]
  label: 'the idle process'
  allowStop: false
  allowDebug: false.
  self registerWellKnownProcess: [Sensor interruptWatcherProcess]
  label: 'the user interrupt watcher'
  allowStop: false
  allowDebug: false.
  self registerWellKnownProcess: [Sensor eventTicklerProcess]
  label: 'the event tickler'
  allowStop: false
  allowDebug: false.
  self registerWellKnownProcess: [Project uiProcess]
  label: 'the inactive Morphic UI process'
  allowStop: false
  allowDebug: false.
+ " self registerWellKnownProcess:
- self registerWellKnownProcess:
  [Smalltalk at: #SoundPlayer ifPresent: [:sp | sp playerProcess]]
  label: 'the Sound Player'
  allowStop: false
+ allowDebug: false."
- allowDebug: false.
  self registerWellKnownProcess:
  [ScheduledControllers ifNotNil: [ScheduledControllers activeControllerProcess]]
  label: 'the inactive MVC controller process'
  allowStop: false
  allowDebug: true.
  self registerWellKnownProcess:
  [Smalltalk at: #CPUWatcher ifPresent: [:cw | cw currentWatcherProcess]]
  label: 'the CPUWatcher'
  allowStop: false
  allowDebug: false
  !

Item was changed:
+ (PackageInfo named: 'Tools') postscript: 'ProcessBrowser initialize.'!
- (PackageInfo named: 'Tools') postscript: '"Updated for new global hot-key support."
- ActiveWorld initializeDesktopCommandKeySelectors'!

Best,
Marcel

Really nice! It's great to see all these updates to the sound system.

Dave

I thought the reason for one global sound process was due to it
needing to "sum up" all the voices of a given instant and pass that
aggregate waveform to some primitive which would play it for that
millisecond (or whatever).

Clearly, my mental model must be wrong.  Sound in Squeak is an area
where I could qualify as a "beginner" any enlightenment would be
welcome.

On Wed, Apr 6, 2016 at 10:49 AM, marcel.taeumel <[hidden email]> wrote:

Hi Chris,

you're right. I mixed that up. Regular sound output has to be a single process while multiple processes for MIDI output can overlap and still produce okay-ish audible output.

Anyway, processes should store flags for debuggability, stoppability, and label in themselves. Simplifies maintenance.

Best,
Marcel

> On 06-04-2016, at 10:01 AM, Chris Muller <[hidden email]> wrote:
>
> I thought the reason for one global sound process was due to it
> needing to "sum up" all the voices of a given instant and pass that
> aggregate waveform to some primitive which would play it for that
> millisecond (or whatever).

As best I understand it the MIDI synthesiser is quite separate and outputs whatever it wants via the system sound handler. Our FM sound(etc) goes out via our own soundplayer process and the prims that add it to the system sound handler.

On the Pi (and therefore I hope generic linux) we recently got a parcel of fixes integrated that make MIDI stuff work decently via timidity; no idea if that means it would work with any other linux midi synth.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Furnulum pani nolo = I don't want a toaster.