Hi,
I am working on a module that employs some of the concepts described by the module tags but can not be easily classified that way (e.g. it employs a physical model but does not do synthesis. Thus I assume that in that case using the ‘physical modeling’ tag is more misleading than helpful). There are also many other modules that can (and should ;-)) be (ab)used in ways that are not necessarily related to the tags.
Apart from the potential need for another tag, this raises the question: Are the tags to be understood as a classification or a nomenclature?
Classification: Entities are members of disjoint classes. Tags are used to describe class memberships. It is desirable to use only one tag (or the smallest possible number of tags) in order to do that.
Nomenclature: There are no classes but properties. Entities are characterized by assigning properties. It is desirable to use all tags that are suitable for describing the entity.
I assume that the intention behind the tags is to presort modules so that selecting a module from a large number of modules becomes more convenient. So it is a classification. However,
-
The assumption of disjoint classes does not hold. Modules can be used in more ways than one class membership indicates. Hence the desire to use multiple tags, turning the monoaxial classification into a multiaxial classification. This increases complexity and therefore might decrease usability.
-
From a musician’s point of view, classification can hinder creativity instead of promoting it. ‘Off-label use’ of plugins often leads to surprising results and should definitely be encouraged ;-), while classification encourages the use ‘as intended’.
Imho, a distinction should be made between the ‘primary purpose’ of a module and its other ‘secondary purposes’. While for the ‘primary use’ an elaborate classification (one tag only!) is the way to go, there could be an additional nomenclature of secondary purposes, ideally with relevance weights attached to each secondary purpose (e.g. from 1-‘far fetched but possible’ to 9-‘obvious’ like using a VCF as an oscillator).
That way navigation is convenient while creativity is encouraged at the same time.
Plus, user feedback could be used to add secondary purposes or change the weights.
What do you think?
For Reference: List of allowed tags in Rack 1.1.0:
“Arpeggiator”
“Attenuator” // With a level knob and not much else.
“Blank” // No parameters or ports. Serves no purpose except visual.
“Chorus”
“Clock generator”
“Clock modulator” // Clock dividers multipliers etc.
“Compressor” // With threshold ratio knee etc parameters.
“Controller” // Use only if the artist “performs” with this module. Simply having knobs is not enough. Examples: on-screen keyboard XY pad.
“Delay”
“Digital”
“Distortion”
“Drum”
“Dual” // The core functionality times two. If multiple channels are a requirement for the module to exist (ring modulator mixer etc) it is not a Dual module.
“Dynamics”
“Effect”
“Envelope follower”
“Envelope generator”
“Equalizer”
“Expander” // Expands the functionality of a “mother” module when placed next to it. Expanders should inherit the tags of its mother module.
“External”
“Flanger”
“Function generator”
“Granular”
“LFO”
“Limiter”
“Logic”
“Low pass gate”
“MIDI”
“Mixer”
“Multiple”
“Noise”
“Panning”
“Phaser”
“Physical modeling”
“Polyphonic”
“Quad” // The core functionality times four. If multiple channels are a requirement for the module to exist (ring modulator mixer etc) it is not a Quad module.
“Quantizer”
“Random”
“Recording”
“Reverb”
“Ring modulator”
“Sample and hold”
“Sampler”
“Sequencer”
“Slew limiter”
“Switch”
“Synth voice” // A synth voice must have at the minimum a built-in oscillator and envelope.
“Tuner”
“Utility” // Serves only extremely basic functions like inverting max min multiplying by 2 etc.
“VCA”
“VCF”
“VCO”
“Visual”
“Vocoder”
“Waveshaper”
