-
Notifications
You must be signed in to change notification settings - Fork 1
/
Beta Plugin Framework.txt
232 lines (203 loc) · 8.04 KB
/
Beta Plugin Framework.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
-------------------------------- BETA PLUGIN FRAMEWORK
by Florian Mrugalla
but open for pull requests in case of additional ideas
or for fixing typos and other mistakes!
:)
-------------------------------- TESTING STAGES OF THE DEVELOPER
1. Steinberg VST3 Validator
2. Pluginval
3. Some DAWs
-------------------------------- CAUTION TO DEVELOPER
Check if your build is compatible with beta tester's setup.
OS
Windows/Mac/Linux
DAW
Does it support the plugin features?
Plugin Properties
VST2/3, Clap etc.
32bit/64bit
-------------------------------- CAUTION TO BETA TESTER
Always use a brickwall limiter on master bus
in case of unintentional feedback loops and other
bugs that can hurt or damage your ears or gear!
Don't use the plugin in important projects, because
changes made in response to beta tester feedback
might affect the behaviour of the final plugin.
-------------------------------- USING AN EXAMPLE
To test this framework, I will use my own plugin release,
NEL, as an example for the various aspects of beta testing.
NEL is a VST3 plugin with diverse ways to modulate a
feed-forward delay in order to apply vibrato to a signal.
Whenever some testing aspect explains an aspect of NEL it is
marked with "e.g.".
-------------------------------- USER TYPES (not a hierarchy. combinations possible.)
BEGINNER
Just started music production.
Has not internalized anything yet.
Drag types of knobs make a big difference.
Visibility and good labels.
ROOKIE
Some years of experience.
Might not know about scrollwheel- and modifier keys yet.
e.g. user dials in simple LFOs and randomized modulators.
ADVANCED
Pretty much every dedicated plugin user.
e.g. user can combine the output of multiple modulators.
SOUNDDESIGNER
Elevated interest in crafting individual sounds rather than finishing tracks.
e.g. user needs to know what audio rate modulation is
DSP NERD
Trys to identify the underlying mechanisms for satisfaction.
e.g. user needs to know how the buffer size of a delay relates to the depth parameter
ANALOG GEARHEAD
Prefers limited plugin features over digital sounds and looks.
MUSIC PRODUCER
Wants an easy and streamlined workflow. (Quantity > Quality)
MIXING ENGINEER
Mixes a song.
e.g. oversampling for a cleaner vibrato-sound on complex signals.
PRE-MASTERING ENGINEER
Applies finishing touches to a song's master bus.
MASTERING ENGINEER
Applies finishing touches to a collection of related songs.
-------------------------------- A PLUGIN IS ASSUMED TO HAVE
1. A TARGET AUDIENCE
Sex
e.g. undefined
Age
e.g. likely >18
SKILL LEVEL
e.g. rookies
e.g. sounddesign nerds
e.g. dsp nerds
AUDIO JOB
e.g. beat makers, sounddesigners, mixing engineers
PASSION FOR DIGITAL MUSIC
e.g. high
WILLINGNESS TO PAY FOR PLUGINS
e.g. low or medium
2. FUNCTIONS
2.1 Technological function(s)
The DSP/Workflow architectures the plugin is composed of.
e.g. have a complex modulation system.
e.g. have a feed-forward delay.
e.g. use the modulation system's output to modulate the delay.
2.2 Musical function(s)
The ways in which the technological functions are musical.
e.g. add vibrato to a signal.
e.g. add scratches to a signal.
e.g. add timing & pitch variations to a signal.
e.g. phase distort a signal. (Audiorate Mod)
e.g. add tape-y pitch dropouts.
2.3 Visionary function(s)
The ways in which the musical functions give meaning to productions.
e.g. promote relevance of vibrato in music.
e.g. shift people's mindsets on usefulness of different vibrato modulation types.
e.g. make the swiss army knife of vibrato.
2.4 Branding function(s)
The ways in which the plugin sets the tone of the developer's brand.
e.g. Mrugalla plugins give existing technological ideas a new spin by combining them in new ways.
-------------------------------- TESTING STAGES OF BETA TESTERS
1. FIRST IMPRESSION
The beta tester is given at least one screenshot
or a video without audio. They are asked what the
plugin probably does, why it was probably made and
which users it probably appeals to.
1.1 How much does the GUI explain itself just from looking at it?
1.1.1 How obvious is the signal flow?
1.1.2 Does the GUI convey what the plugin is useful for?
1.1.3 Which elements cause misunderstandings?
1.2 How appealing / aesthetical does the GUI look?
1.2.1 Does the overall style fit the supposed target audience.
e.g. Flat interface for digital music producers.
1.3 How functional does the GUI look?
Check for unfortunately placed parameters.
Check for empty / unused spaced.
1.4 Vibe Check
1.4.1 Does the plugin look hard to use, or easy?
2. BLIND TEST
The beta tester is given a plugin build, but no manual or
explanation of the plugin's function(s) yet.
2.1 To what extend does the plugin explain itself?
2.1.1 Which functions are overlooked?
2.1.2 Does the user find new unexpected functions?
2.2 How much are the plugin's functions being noticed?
2.1. OVERLOOKED MOSTLY
e.g. people rarely find the buffersize feature.
e.g. using more than 1 macro modulator.
e.g. adjusting the interpolation type.
2.2 NOTICED RARELY
e.g. mixing 2 modulators with each other.
e.g. dialing in macro modulation.
2.3 NOTICED SOMETIMES
e.g. different modulation types in drop-down menu.
2.4 NOTICED A LOT
e.g. stereo-width, mid/side.
2.5 ALWAYS USED
e.g. depth, speed, mix.
3. EXPLAINED TEST
The user is informed about the plugin's functions,
but without explaining how to accomplish them.
e.g. You can use the plugin to add livelyness to a sterile drum part.
3.1 How does the user approach the plugin now?
3.1.1 In which way(s) is it different or similiar?
3.1.2 Does the user succeed to accomplish the plugin function?
4. INFORMED TEST
The user is told how to accomplish the plugin's functions.
4.1 The user rates how likely it would be that another user accomplishes the functions.
4.2 The user attempts to formulate the reason why certain functions weren't obvious at first.
5. STRESS TEST
The user is told to play around with the plugin in the context of
some actual practical work (beat, song etc.)
5.1 Find out in which kind of situations the user chooses the plugin.
5.1.1 If the user decides against it, why?
-------------------------------- TYPES OF DOCUMENTATION
1. VIDEO
1.1 Advantage of revealing the way a plugin is being used.
1.2 UNEDITED
How does the user navigate the plugin interface?
What does the user's facial expression reveal?
Where does the user get stuck?
1.3 EDITED
Which functions are highlighted in the video?
1.4 BOTH
What seems most fun?
Which other plugins need to be used to use this plugin?
2. TEXT
2.1 Advantage of being a fast communicative process.
You can discuss misunderstandings better than via videos.
-------------------------------- EXPECTATIONS FROM THE DEVELOPER
Considering a developer is open for all kinds of criticism,
here are potential categories of criticism:
1. BUGS
1.1 Audio/DSP Bugs
2. REQUESTS
2.1 Features
2.1.1 Features that could still fit into this plugin.
2.1.2 Features that are potentially outside the scope.
2.2 Soundquality
2.2.1 Some sounds are not 'broken', but could just be better.
2.3 Workflow
2.3.1 When the interface makes certain aspects inconvenient.
2.3.2 When the interface makes it almost impossible to accomplish certain tasks.
2.3.3 When the controls are acting in an unusual/unexpected way.
2.3.4 When the layout feels confusing.
2.4 Design
2.4.1 When the design distracts from the function of the plugin.
2.4.2 When the design is not appealing.
2.4.3 When the colours make things hard to look at.
2.4.4 When certain controls or labels are too small or blurry.
--------------------------------
--------------------------------
--------------------------------
--------------------------------
--------------------------------
--------------------------------
--------------------------------
--------------------------------
--------------------------------
--------------------------------
--------------------------------
-------------------------------- NOTES / THINGS THAT DONT HAVE A CATEGORY YET
cpu/ram performance
logging