MSoundFactory concept & template round #3

[MeldaProduction]

dmbaer: The best way imho is to do everything as normal presets in the edit screen and only then after you are finished, save it as a device (as as DarkStar suggested). Think of Devices as the final product to be deployed to the end users.
There shouldn't be any difference between loading instruments and normal presets except that I think when loading a device the MPs are automatically set to defaults, not sure though. I think it at least was like that at some point, because in many cases people forget to set the MPs to defaults when creating the devices and testing them.

elassi: I'm not sure how to understand that and I don't really remember Riemann's conjecture, but I remember Godel's incompleteness' theorems (freely translated), which basically said that in every theory there's something, that cannot proven nor disproven, not sure if that's helpful though . The proof had 20 pages and I never fully understood it .

[dmbaer]

Au contraire, mon brave!

F1 should not be turned off. This is a good illustration of something I posted earlier: given that a lot can go on "under the hood" of MSF, it is essential that all MSF instrument designers provide good Info about the Easy screen parameters. Otherwise users will be faced by knobs and sliders and not know what they are meant to do. As MSF is in beta at the moment, and Vojtech is "a bit busy" , he is excused for the moment.

My suggestion was based upon the assumption that control-level help would not be present for MSF devices/presets. If you read back through the posts a couple of pages ago in this thread, Vojtech made the argument that it would not be needed. And if you look at the template that's supposed to be used for "official" device development, none of the controls in the template have it, so that lack will be propagated in perpetuity.

IMO, it does no good to have control-level help present in a hit or miss fashion. If it's only there for, say, one control in eight, people will simply stop trying to use it after experiencing a major feeling of annoyance. Thus, my suggestion that F1 control help is better left non-functional if all it gets you is a window of useless information.

[MeldaProduction]

The template now contains the help actually (get the latest version please), but not for effects, since there it doesn't make much sense, after all what you want to write about Autopan / Enable and Autopan / Rate .

[dmbaer]

dmbaer: The best way imho is to do everything as normal presets in the edit screen and only then after you are finished, save it as a device (as as DarkStar suggested). Think of Devices as the final product to be deployed to the end users.
There shouldn't be any difference between loading instruments and normal presets except that I think when loading a device the MPs are automatically set to defaults, not sure though. I think it at least was like that at some point, because in many cases people forget to set the MPs to defaults when creating the devices and testing them.
pful though .

If the run-time platform behaves differently than the development platform, especially in a critical area like variable initialization, and especially if the development platform is more forgiving than the run-time platform, it's naive and downright foolhardy to suggest doing development and testing on the development platform, doing a save, and then you're done. This isn't a criticism, it's a simple fact of software life.

So advising device developers that this is an OK way to work is dangerous and will almost certainly result in devices that don't work properly.

In the old way of doing things, MP defaults were only needed for allowing the user to easily reset the value to the default - at least that's my impression of how things behaved. MP defaults were pointless for bank MPs, switches and non-visible MPs. Plus it was easy to simply forget to set a default.

One thing that might be of use in this new way of doing things is to have a button on the save-device dialogue for "set all un-defaulted MPs to have current value as default" (OK, there's probably a better way to say that ). The idea would be to go through all MPs, including those in ModularEx modules, and give any without an assigned default value the current value as the assigned default value prior to saving a device. This would not eliminate the need for rigorous testing of a saved device, but it might reduce the number of errors that will certainly be attributable to the differences between development and run-time variable initialization.

[MeldaProduction]

Hmmm, I must say I'm quite confused, seems to me like some evil is flying around . There's no development platform or anything, not really sure what you wanted to say by that.
In any case if you save something as a preset and a device, then load each, they should sound the same. If not, my only explanation is that the device set all MPs to their default values (which has actually proven quite handy in the feature). It could of course be a bug, but for that to check I'd need some actual settings.

[DarkStar]

My 2p:

If the platforms behave differently (and I cannot see how presets inside a plug-in would), then the cycle would be:
-- develop and test on the development platform,
-- save an instrument / device,
-- export to the run-time platform,
-- test there too,
-- if faults found, then back to step 1.

However there are hundreds / thousands of potential run-time systems and no instrument designers would be able to emulate anything like that.

All MPs have a default value - either the one set by the user by clicking the button, or a value of 50% (the "default default" that I mentioned above. And a default would be relevant for a bank MP or switcher etc.

Having a button to "Set the current values of those Multiparameters without set defaults as defaults" could be useful, but it seems to me to be more straight-forward to set the default when you create each MP.

I cannot think of any "differences between development and run-time variable initialization". Have you got any specific examples?

[dmbaer]

OK, let me try to clarify. I have been assuming that with editing presets (not devices) that when you load one you get the last saved MP values. If I'm wrong about this, then never mind. However, I encountered some issues all of a sudden when editing a device (not preset) that *seemed* (could be wrong!) to work differently due to different initial MP values than what I saw when working on the same thing as a preset (not device).

If this is so, then it should raise some concerns. But it's entirely possible my issues were due to some other error on my part (I've still sort of got the training wheels on in this pursuit).

If this is not the case, then very sorry for raising a false alarm!

[dmbaer]

Another question on standard practice. Should we include a "default" preset that's the same as the initial device configuration. The thought here is that having loaded a device and checked out a few presets, the user might want to start over and create a new preset of his own. Of course, the device could just be reloaded and you'd accomplish the same thing. I'm only asking because if this is to be common practice, it would be of benefit to call the default preset the same thing everywhere (like "default"). And unless it's done consistently, then there probably should be no default presets defined just to keep things uniform.

[MeldaProduction]

So another repeat - there are no development / release platforms or anything . If things work, then assuming MSoundFactory works on the target system, it should work exactly as in your place.

About the default presets for instruments - well, I'd say "yes", but it's probably nothing too imperative. But yes, it's a good practice.

[DarkStar]

Ah, I think I see the confusion.

In a preset:
-- every parameter has a default value, hard-coded.

In a preset with Multiparameters:
-- the preset has an Easy screen,
-- every MultiParameter (on the Easy screen or Edit screen) has a default value, either set by the user or the default value of 50%,
-- every parameter has a default value, hard-coded.

In an MSF Instrument:
-- the instrument has an Easy screen,
-- every MultiParameter (on the Easy screen or Edit screen) has a default value, either set by the user or the default value of 50%.

Try this:
-- load Supersaw and change its Main Osc Unison value
-- Ctlr_Alt_click that knob to open its MP editor and "Set the current value as default"
-- change the Main Osc Unison value again, away from the default value,
-- from the Edit screen, Save it as a Preset and as a Device,
-- switch to Slot B (in a..H slots), load the saved Device, check the knob's default value,
-- switch to Slot C (in a..H slots), load the saved preset, check the knob's default value.

[dmbaer]

So another repeat - there are no development / release platforms or anything .

OK, these two terms (run-time platform vs development platform) were ones I coined to distinguish between two modes of operation - bad choices in retrospect but my many years as a software developer made me think in terms of development vs run-time platform.

What there is, I think unquestionably as the next post in the thread will demonstrate, are two different loaders, or at least two different loading modes. But sorry about the "platform" choice of words to distinguish these.

[dmbaer]

Try this:
-- load Supersaw and change its Main Osc Unison value
-- Ctlr_Alt_click that knob to open its MP editor and "Set the current value as default"
. . .

Great minds think alike and all that. I had the very same idea to test and possibly demonstrate that preset loading was different between edit-preset loading and device loading. I created a minimal MSF preset:

Code: Select all

$eNqlltty4jgQhu95CpWyl0N8AAJTZXsqIZBNTQgsJpnspbAbUCFLlCQnsE+-JR9wAgx4a30l-fq6Wy3JUns-tglD7yAVFdzHzrWNEfBIxJQvfZzqRbOHfwQNbxSKlMdDEmkhdwq0pnyp0JWPHYyuHpiYE6ZmZO5jF6OHl8eQ-gOuj5227X7rdtp7bUDUzuiu8z3X--zrZaNIsmFZPBujp2m4YVRrkIZ3fOzYnSPZ9XHLxmhEtk-D8R0T0dqoPm65GI1SpumESJKABqn6gjGyURBn3l-LRLu97x27jQMvTOcTli4pL3ILvLwbfs3xZKgQGEQa4tzCx-Y3G5f2ygo866urwLOOojU+TeDt-8V2q9hlAw1Txp5JAj5+0ZRRvUMORl8EjN6ylfnbbN1vJnDVFzHITytptPt+NqNjHRjZDTiZM4gPhgb8HZjYwG9GtxsJKt+e7Zf+aX5E9Or0yHQUnhw4tZDVNu0b6vzOvQUNb8DfncCbSUgEE+GKbACFs8FkMh2Eg5lZT+M2gzLWrcO6Oduqw7Zytl2Hbedspw7bydmbOuxNznbrsN2c7dVhe0HDy2+UAX+-aFCRDe9pOHbQE-ClXmUX0SGdEe5FonWRaF8kOheJm4tE9yLRO09MCY9Fkh1UwtVCyIRoKjgaPL+WYC9bxBIsTdy6Ju7epFXXpLU3adc1MSf4J+xURBjUyKZCKzO3vpnJ6RWYiKiuHfKAP3Dg-kcHn2dwiDYqVxNzPaYSziFUR6s74PEZZiTiXysAdgaZ0WQuods+g9xJIHplu2eQ6kJ3nDPYs9AwXiyOiQdGY8jvgaOxvuBaCsZAKhRSvmTQXxHOgZX-wkFZEBwINrojfN0XKdc+7uCsZ95J28chE9o8m6XkFJKLmugeFiRluhp0i8FWJbUKqV1J7ULq4NLDK2Ep+Ni+drt5BTWIqRZyJGLw8bM5NwyjvGecqPIVn4HSmVuMwg2UVU7prOO4Ra8w3aE54WvESQLmsS+zR4OtnoLKHklTMkwJX4KP2xg9cg1yIxjRkLnem+Thh2+oifalBWqiO6JohJpoQriQJCHVZHDwR-Mn39prh0b3vdv8u19PPorm+LZZtG671fjH5MP3PWsfNvCsg407UlTQ8G4jTd-B-CCgUVkEzCTkSZi1NbkGXp9oWAq5e9SQPPKFsAKvn0oJ-IRVnvFYLgm3piJaW0+CxCCR2YLr5JErLdMEuP7kNtREQ+ANgehUgsoCm7rEBDd--QFnFbEDz-qcgMlHbtA02wNTsTS8UXGIx6keoXuqNozsRmRLkzQpHsZfNNarUeCFIpURoImEBWUaZFFnm+glYhXeGp51qsxXQeNfUQvc2A==

There is a single control, a bank with five slots. To demo, paste it in, click on slot 2, open the MP editor and click "use current value as default". Now you know for sure to what the default was set.

Next, click on slot 4. Save the preset and then save as a device. Use a name of your choice.

In a new instance of MSF (not actually necessary, but just to be 100% sure there's no "contamination"), load the preset with edit-load. You should see slot 4 selected.

In a new instace of MSF, use load device in non-edit mode. You should see slot 2 selected.

So, we have proof, I think, that there are two different loader modes that work differently depending on with you are loading an edit-preset definition or a device definition.

What this strongly suggests is that a sound developer who gets a device to the point of serious testing should only do so using the device loader. Using the edit-preset loader could easily initialize the device to a different state than the device loader would have. Any testing not using the device loader would therefore be suspect.

QED (and I should have set up this test a couple of days ago to avoid all the speculation we've been engaging in)!

[DarkStar]

Ah ha - now I see the light.

• The preset is saved, storing the last-entered value and the selected default. It loads with the last-entered value.
• The device is saved, storing the selected default. I cannot tell what it does with the last-entered value. It loads with the selected default value.

On reflection, this seems to be a bug; both should load with the last-selected value. If the designer wants the device to load with the default value, then he/she should make sure that the MP is set to its default value before saving as a Device.

---------------------------
PS Bug in the Device browser: I deleted the device in the "Save Device" window, but it remained listed in the Browser and could still be loaded.

[dmbaer]

PS Bug in the Device browser: I deleted the device in the "Save Device" window, but it remained listed in the Browser and could still be loaded.

I've noticed this as well. Probably just a matter of needing a refresh. The deleted device should be absent from the list if you start a new instance of MSF.

[MeldaProduction]

dmbaer: The difference is in the MP defaults, correct? (I didn't check)

As for Delete device - yeah, that probably needs restarting the plugin, I'll check about that. Never expected people to do that .