Re: [Csnd-dev] Default values

For practical purposes, having an "undefined" signature char for each type
would suffice, the actual default can be set at the init callback (I am
speaking of actual opcodes, not user defined ones). This has the benefit of
being backwards compatible.



On Mon, Nov 25, 2024 at 3:07 PM Steven Yi <[email protected]> wrote:

> Definitely think we should have a default value system that replaces
> the hack-ish use of pseudo-type characters to represent certain values
> (0, -1, 1, etc.). The new-style UDOs would definitely be easy to
> update for this from the language side, something like:
>
> opcode myOpcode(freq:i = 440, amp:i = 0.25):a
> ...
> endop
>
> Internally, we'd probably need to modify OENTRY to accommodate storing
> the default value for a pfield. It potentially becomes an arduous task
> if we fully go and replace how we declare input and output arguments,
> moving away from a single string to something like an array of
> argument structs. Migration would be a pain, but the end result would
> be a much clearer and flexible way to deal with arguments to opcodes
> in our system.
>
> On Mon, Nov 25, 2024 at 7:29 AM Eduardo Moguillansky
> <[email protected]> wrote:
> >
> > Hi,
> >
> > Default values for parameters, together with named arguments, have been
> discussed before. At the moment there is no way for an opcode to define
> default values outside of some simple cases, like 0, -1 or 1. There are
> cases where all of these are actually plausible values and it is not
> possible to indicate that a parameter is unset at init time. I would like
> to propose a new variable signature, different from o/O(=0), p/P(=1) or
> j/J(=-1): u/U (undefined), which would receive a nan value. The opcode
> would check that at init time and set it to a sensible default.
> >
> > The same thing could be done for UDOs, although I would like to see
> actual default values implemented.
> >
> > cheers
> > eduardo
> >
>