Still strugling with indents

One line of code , on first line ,synthfdef from tutorial, plays when selecting last parenthese

SynthDef.new("tutorial-SinOsc",{ Out.ar(0, SinOsc.ar(440, 0, 0.2)) }).play;

Split the code and it doesn’t
This is driving me nuts , really

SynthDef.new("tutorial-SinOsc"
	,{ Out.ar(0, SinOsc.ar(440, 0, 0.2)) }).play;

No. It is that it is on one line of code. Once you split it over multiple lines, you need to select the whole chunk of code before running it.

But that only applies to synthdefs, no ?

I have multiple lines of codes , as long as they are in between ( ) it can be split as many times as I like

But they aren’t. The .play is outside the (). Put a ( at the front and a ) at the end and command-return will work.

Sam

Yeah I missed that
late at night :slight_smile:

So here’s the thing about code regions in parentheses.

You need to start the region with an open-paren on a line by itself.

And you need to close the region with an close-paren on a line by itself (maybe a semicolon after this one is OK too).

If you write it like this:

(
SynthDef.new("tutorial-SinOsc"
	,{ Out.ar(0, SinOsc.ar(440, 0, 0.2)) }).play;
)

… then you can use line breaks as you like. (Though it’s quite odd to split the line before the comma, instead of after.)

Your original example does have parentheses in it, but they are in the middle of the block. So you should not expect those parentheses to delimit the entire block.

PS And no, this doesn’t apply only to SynthDefs. Why would it?

hjh

Anyway still some isses ,here’s a help file from the gendy u-gen
I spaced the first parenthese in the help file and it still plays
When pasting it in the ide it doesn’t

from help file
// wahhhhhhhh- try durscale 10.0 and 0.0 too
(
{
Pan2.ar(
CombN.ar(
Resonz.ar(
Gendy1.ar(2, 3, minfreq:1, maxfreq: MouseX.kr(10, 700), durscale:0.1, initCPs:10),
MouseY.kr(50, 1000), 0.1),
0.1, 0.1, 5, 0.6
),
0.0)
}.play
)

from ide

// wahhhhhhhh- try durscale 10.0 and 0.0 too
           (
        {
            Pan2.ar(
                CombN.ar(
                    Resonz.ar(
                        Gendy1.ar(2, 3, minfreq:1, maxfreq: MouseX.kr(10, 700), durscale:0.1, initCPs:10),
                        MouseY.kr(50, 1000), 0.1),
                    0.1, 0.1, 5, 0.6
                ),
                0.0)
        }.play
    )


I really think this is a bug , the ide gives a console error with first parenthese is spaced a few nothes , the help file does not

I can confirm something strange that I’ve never realized so far: indenting the first parenthesis disables region evaluation!

// first parenthesis indented
// region can't be evaluated with cursor inside parenthesis
	(
        {
            Pan2.ar(
                CombN.ar(
                    Resonz.ar(
                        Gendy1.ar(2, 3, 
							minfreq:1, maxfreq: MouseX.kr(10, 700), 
							durscale:0.1, initCPs:10							
						),
                        MouseY.kr(50, 1000), 0.1),
                    0.1, 0.1, 5, 0.6
                ),
                0.0)
        }.play
    )

// first parenthesis not indented
// region can be evaluated with cursor inside parenthesis

(
        {
            Pan2.ar(
                CombN.ar(
                    Resonz.ar(
                        Gendy1.ar(2, 3, 
							minfreq:1, maxfreq: MouseX.kr(10, 700), 
							durscale:0.1, initCPs:10							
						),
                        MouseY.kr(50, 1000), 0.1),
                    0.1, 0.1, 5, 0.6
                ),
                0.0)
        }.play
    )

From my experience it is like this: there seem to be cases when region evaluation is possible and others when it is not (e.g., there seem to be issues with comments). When encountering such a case, I automatically choose a “manual” selection, either by dragging the mouse or by double-clicking inside one of the enclosing brackets. Both of the latter ways work here too (SC 3.11.1, Catalina).

Here are the rules for region detection as I understand them:

  • The region must begin at indentation level 0. This requires two things:
    1. Any bracketing pairs earlier in the file should be closed. If you have an open-paren somewhere earlier and it doesn’t have a matching close-paren, region detection anywhere after that point won’t work.
    2. The region’s open-paren should be at the left margin. (If your file meets condition #1, then IDE auto-indentation will put the paren flush left. So, if auto-indentation added space before the paren, then you know there’s a bracketing problem earlier in the file.)
  • Better practice is to open the region with a left-paren on a line by itself (but I’m not sure if that’s a hard rule).

#1 is logged as an issue, but I think the behavior won’t be changed.

Taking the example from that issue: Let’s say you write this:

{ Saw.ar([200,300]) }.play;

(
1+1;
1+2;
)

Both the line and the region work as expected.

Now you want to add a LFO to the synth, but you got mixed up with the brackets and left out one closing paren (easy mistake to make):

{ Saw.ar(LFNoise1.kr(1).range(100,[200,300]) }.play;

(
1+1;
1+2;
)

Now, not only is there a syntax error in the synth, but also the region below it fails to be detected (cursor on left paren --> syntax error, cursor on one of the code lines --> only that line runs when you expected the whole block to run).

The reason is that the IDE “tokenizes” every code document, to understand what is an identifier, what is a number, how many bracket levels are open, etc etc. With the syntax error in the last example, then… at the start of the region, the tokenizer is at indentation level 1 – not 0 as required to find a region.

Also, note what happens if you select all the code in that example and hit tab to re-indent:

{ Saw.ar(LFNoise1.kr(1).range(100,[200,300]) }.play;
	
	(
		1+1;
		1+2;
	)

If the auto-indenter does this, then you know brackets are mismatched and region detection will fail.

“But when I’m running the region, I don’t care about mistakes earlier in the file. It should magically reset, shouldn’t it?”

But how should it reset? Based on what? If you think about it, there kinda isn’t any way to reset, except to close all the parens. (Also, there’s not really a compelling reason to encourage users to maintain malformed code in their scd files. If you have bad syntax, it means you have code blocks that can’t be run = parts of your file are useless. The solution, then, is to fix the code blocks so that they do run.)

I suspect what is happening here is that you’re copying bits of code somewhat haphazardly into one document, accidentally introducing syntax errors which cause later regions not to be found. Then the impression is that code execution is broken at random times. But there is nothing random about it.

Like it or not, programming languages are strict about small details. There really is no other way except to tune your mind into these details, to the point that the Saw example I copied from github should “feel unbalanced” even before counting parens… “something looks wrong.” Without developing this sensitivity, things will continue to seem to break randomly.

hjh

Even after five years of using SC, I still occasionally catch myself commenting:

// :( 

…with obvious consequences.