[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] phosphor - freeframe

it's kinda a project. we do have a mailing list.

thanks for the info.

in a few months i'll have a graphics engine complete. i will need to port it to the mac though, since it writes directly to the frame buffer in windows. so... if anyone knows anything about writing pixels directly to the frame buffer on a mac, i could use your help. the rest of the code should be platform neutral, as long as that platform supports OpenGL.

On Thursday, January 29, 2004, at 06:43 PM, James McCartney wrote:

If phosphor is an actual project, then those interested should probably take a look at freeframe

There are things I really don't like about it.

The pixel data type specification is limited to only a few types, is not descriptive or extensible, thus I think will not evolve well over time.
32-bit unsigned integer. Specifies certain capabilities of a plugin that the host may want to enquire about.:
0 = 16-bit 5-6-5 pixelformat support
1 = 24-bit pixelformat support
2 = 32-bit (or 24-bit 32-bit aligned) pixelformat support

They perpetuate the (IMHO) really stupid VST design mistake of shoving all parameters into 0-1 range, which makes setting parameters in exact units difficult, and makes all stored settings break if you decide later to change your plugin's range of reponse. This is especially a problem for discrete values. If you change a discrete valued parameter from supporting 5 discrete values (0, 0.25, 0.5, 0.75, 1.0) to 8 values, then all of the stored settings will be wrong.

FreeFrame parameter values are always 32-bit floats, and the range of values permitted is STRICTLY 0-1 (0 <= ParameterValue <= 1). This allows faster processing and a good range of values over a standard range, so the host can run up sliders or similar for the plugin. The Use of any values outside this range will result in hideous incompatibilities. The ParameterDisplayValue can be used to display whatever actual values the plugin likes e.g. 0-255, 0-767, 1-256 or whatever. The plugin should translate the standard 0-1 float range into the values it needs for its processing.
For text parameters, this 32-bit value represents a pointer to a null terminated string.

But having a standard is a good thing to take advantage of.

--- james mccartney james@xxxxxxxxxxxxxx <http://www.audiosynth.com>
SuperCollider - a real time audio synthesis programming language_______________________________________________
sc-dev mailing list