What will the design and optimization algorithms require from "instruments"?

[bhp1]

What general functionality will the design and optimization algorithms need from an "instrument" class. As noted in Modelling Instruments, I think (hope) it may reduce to functions that map from playing configuration and frequency to things like impedance.

Each instrument would need its own UI, but that could be encapsulated within the class.

[edwardkort]

I'm just brain-storming here, but I believe that any geometry feature unique to a particular instrument is a candidate for design and optimization. Ultimately, the calculation engine will be operating on generic acoustic components, but the design and optimization algorithms must point back to the "raw" geometry that is unique to each instrument type.

A few possible scenarios:

1. Tonehole height - on the sax, tonehole height is pretty much an independent variable for each tonehole; on a recorder, this height is still somewhat independent, being the wall thickness subject to indents and tapers; on the NAF, there is very little room for change.
2. Mouthpiece/embouchure - different instruments will need very different sets of parameters, with different subsets being subject to change.
3. Bore perturbations - the extent and "adjustability" of bore profile changes varies widely between instruments. Most woodwinds have straight or simple-curve tapers; some have complex profiles with no adjustability (bamboo instruments); some utilize localized perturbations (globs of material in the bore of the shakuhachi).

I see as much reuse of the "common" raw geometry components as possible, but I believe there are also some components that only make sense for a particular instrument.

And one of the prime design rules of Agile (and now general OOP practice) is do not overload a class. You end up changing too much code as new children of that class are implemented.

[antoinelefebvre]

Some quick brainstorming.

I think we can have a generic geometric model of the bore and specific models for the mouthpiece/embouchure.

In my previous optimization work, I considered the bore as a concatenation of cone segments (diverging, converging or cylinders are all covered by the same model) plus a list of toneholes.

More on this later.

Then, each possible design parameter ismarked as 'FIXED' or 'FREE' depending if we want them to be optimized. For instance, a tonehole can have a FIXED height and FREE diameter (its position is always FREE).

The same is true for the bore diameter. They can be considered FIXED or FREE. The number of optimization variable will thus depend on those settings.

For each of the optimization variables, bounds are specified:

• min and max distance between adjacent holes
• min and max ratio of tonehole radius to bore radius

For the height of the toneholes, it is useful to define a height that is a function of the position of the tonehole, to accomodate instruments with varying wall thickness.

[edwardkort]

This all sounds good.

How much flexibility do you see the user having in setting the FIXED or FREE attributes? Do we define a superset of FREE parameters that the user can further restrict to FIXED (or just set equal min and max values)?

I will try to upload a first pass at the XSDs for the instrument data by Monday COB.

[bhp1]

Do I have the question backward? I was thinking that design and optimization algorithms would call generic functions of an instrument object. Perhaps instead the instrument objects should call analysis and optimization functions to analyze and optimize themselves.

[bhp1]

"Free parameters" may be misleading. Optimization can change them, but only within particular constraints or invariants.

I think there are more like three levels of parameters. There are parameters that we truly want to keep fixed--because they are determined by the materials we work with, because that part of the instrument is already made, or because we like them the way they are. There are parameters that the optimization is free to change, although usually only within particular limits, and perhaps with limitations on granularity--our pipe may come only in specific diameters or thicknesses. And there are those other parameters: the optimization can change them, but only to re-establish some design invariant.  

Another way to look at it is that we have parameters and constraints. Some of the constraints have the form x=n, fixing a single parameter to a single value. Others may involve multiple parameters. Some are equalitities, others are inequalities.  

Would it be helpful to list the sort of constraints we may want to deal with?

[antoinelefebvre]

Yes, there are parameters and constraints. Parameters are always bounded and continuous. From my experience, using standard multi-variable optimization routine, the only way to work with a set or possible values (granularity) is to perform multiple optimization runs with those parameters fixed at each of these possible values and them to select the result we prefer.

In term of our software, I think we will want to support the notion of "studies", that is, for one particular instrument design project, we will want to run various optimization problems with differing parameters and be able to compare them.

Maybe we will want to write our own optimization routine instead of using standard ones such as the L-BFGS-B routine that I have been using for years. This is not trivial so I guess we may consider that option only once we attain a point where it becomes necessary.

[edwardkort]

And for our OOD, think model-view-controller rather than heavy-weight classes. The Instrument class is likely to be quite small, really just a container for the specified geometry.

[antoinelefebvre]

I agree.

[bhp1]

"Studies"... I like that. Another way I'd put it is "what if" exercises.

[bhp1]

No objections to MVC, but I think there is also a separation between the instrument (model) and the user controls to "build" instruments, and the optimization algorithms and the user controls to run studies.

[edwardkort]

I only brought up MVC as an example design pattern that all would be familiar with. As a "complete" pattern, it is typically too simple. Some of the patterns that we will use will be the result of refactoring in response to "code smells" (google, there are about 27 formal smells). Others we will use from the start (google Agile principles of object-oriented design). The best time to discover the applicable patterns is when we are rapidly changing our codebase: most patterns serve to limit the amount of code that must be modified during such changes.

[edwardkort]

Let me throw out a first-pass at persistence for the data holding the above:

• Project [1]
  • Environment [1]
  • Flute [1]
  • Geometry [1]
  • Scale [1]
  • Temperament [1]
  • Fingerings [1]
  • Study [1,unbounded]
  • Constraint [0,unbounded]
  • Parameter [0, unbounded]
  • Default - fixed [1]

Thoughts?

[bhp1]

A couple of thoughts:

• I think the geometry determines the repertoire of fingering patterns, or more generally of possible playing configurations.
• I'd like a clear separation between:
  • the data that describes the instrument family, which determines what possible dimensions there are (e.g., the instrument body is a tube with a length, an inside radius, and a thickness), and
  • the actual values of those dimensions (e.g., length = 280 mm, radius = 6 mm, thickness = 2 mm), which correspond to a specific design.

In optimization, we'll want to change the value of (some) dimensions, without changing any of the attributes that determine the instrument family.

[edwardkort]

Please see my comments in https://github.com/edwardkort/WWIDesigner/issues/3 concerning the instantiation and persistence of the components of an instrument's tuning.

[edwardkort]

I am closing this thread. There is now a clear separation between data (geometry), calculation (impedance and reflectance), and optimization (which is still tightly linked to constraints).