Hi All,

I'm using the latest from the develop branch and there's some debug
printing going on regarding UDO calls that happens even when -m0 is
on. Does this ring a bell to anyone? I'm having difficulty finding the
source of this (assume to be a printf somewhere).

Thanks,
Steven

p.s. messages look like this:

#i76    in_scale        -2      0       0
        sbus_mix        0       al      ar      0
        sbus_mix        0       al      ar      0
        sbus_mix        0       al      ar      0
        sbus_mix        0       al      ar      0
        sbus_mix        0       al      ar      0
        sbus_mix        0       al      ar      0
        sbus_mix        0       al      ar      0
#i76    in_scale        -2      0       0
#i76    in_scale        -2      0       0
#i76    in_scale        -2      0       0
#i76    in_scale        -2      0       0

I have not come across it, but I'll have a look
tomorroe.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
> 
> *Warning*
> 
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> 
> Hi All,
> 
> I'm using the latest from the develop branch and there's some debug
> printing going on regarding UDO calls that happens even when -m0 is
> on. Does this ring a bell to anyone? I'm having difficulty finding the
> source of this (assume to be a printf somewhere).
> 
> Thanks,
> Steven
> 
> p.s. messages look like this:
> 
> #i76    in_scale        -2      0       0
>        sbus_mix        0       al      ar      0
>        sbus_mix        0       al      ar      0
>        sbus_mix        0       al      ar      0
>        sbus_mix        0       al      ar      0
>        sbus_mix        0       al      ar      0
>        sbus_mix        0       al      ar      0
>        sbus_mix        0       al      ar      0
> #i76    in_scale        -2      0       0
> #i76    in_scale        -2      0       0
> #i76    in_scale        -2      0       0
> #i76    in_scale        -2      0       0
> 
> Seems to happen when the UD

No sign of these messaes in my tree as far as i can tell

Are the sbus_mix strings in your code? Dittp in_scale/


On Sun, 9 Jan 2022, Victor Lazzarini wrote:

> I have not come across it, but I'll have a look
> tomorroe.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>>
>> *Warning*
>>
>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>
>> Hi All,
>>
>> I'm using the latest from the develop branch and there's some debug
>> printing going on regarding UDO calls that happens even when -m0 is
>> on. Does this ring a bell to anyone? I'm having difficulty finding the
>> source of this (assume to be a printf somewhere).
>>
>> Thanks,
>> Steven
>>
>> p.s. messages look like this:
>>
>> #i76    in_scale        -2      0       0
>>        sbus_mix        0       al      ar      0
>>        sbus_mix        0       al      ar      0
>>        sbus_mix        0       al      ar      0
>>        sbus_mix        0       al      ar      0
>>        sbus_mix        0       al      ar      0
>>        sbus_mix        0       al      ar      0
>>        sbus_mix        0       al      ar      0
>> #i76    in_scale        -2      0       0
>> #i76    in_scale        -2      0       0
>> #i76    in_scale        -2      0       0
>> #i76    in_scale        -2      0       0
>>
>> Seems to happen when the UDOs are called
>

These are all names of UDOs; these print messages are breaking up
audio and making live coding impossible. No idea yet where it's coming
from.

On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>
> No sign of these messaes in my tree as far as i can tell
>
> Are the sbus_mix strings in your code? Dittp in_scale/
>
>
> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>
> > I have not come across it, but I'll have a look
> > tomorroe.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> >> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
> >>
> >> *Warning*
> >>
> >> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> >>
> >> Hi All,
> >>
> >> I'm using the latest from the develop branch and there's some debug
> >> printing going on regarding UDO calls that happens even when -m0 is
> >> on. Does this ring a bell to anyone? I'm having difficulty finding the
> >> source of this (assume to be a printf somewhere).
> >>
> >> Thanks,
> >> Steven
> >>
> >> p.s. messages look like this:
> >>
> >> #i76    in_scale        -2      0       0
> >>        sbus_mix        0       al      ar      0
> >>        sbus_mix        0       al      ar      0
> >>        sbus_mix        0       al      ar      0
> >>        sbus_mix        0       al      ar      0
> >>        sbus_mix        0       al      ar      0
> >>        sbus_mix        0       al      ar      0
> >>        sbus_mix        0       al      ar      0
> >> #i76    in_scale        -2      0       0
> >> #i76    in_scale        -2      0       0
> >> #i76    in_scale        -2      0       0
> >> #i76    in_scale        -2      0       0
> >>
> >> Seems to happen when the UDOs are called

I tried to make a minimal test but it also passed. I realized that -m0
changed behavior and errors did not show up in the log. When I turned
that off I got all the messages I didn't want plus the actual error
messages I did want:

PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
#i76    in_scale    -2    0    0
   note aborted
PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
initialised
 from file livecode.orc (2), from file
/Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
0    al    ar    0
   note aborted
PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
initialised
 from file livecode.orc (2), from file
/Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
0    al    ar    0
   note aborted

This code runs fine and has run fine for ages. It seems two things are
happening:

1. Messages were removed from output that shouldn't have. I do not
like that -m0 changed. What happened here? Either way it still printed
the #i76 lines which made this very confusing.  It also probably
breaks some host code of mine in Blue and other projects, but I really
don't have the time to investigate.
2. Something changed with UDO calling. If I rollback to a commit a few
weeks ago the project runs fine, so this is a new problem.

I did a git bisect session yesterday but it lead to commit that I do
not thing was the source of the problem:

Your branch is up to date with 'origin/develop'.
(base) stevenyi@stevens-MacBook-Pro csound % git bisect start
(base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
(base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
Bisecting: 179 revisions left to test after this (roughly 8 steps)
[aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
(base) stevenyi@stevens-MacBook-Pro csound % git bisect good
Bisecting: 89 revisions left to test after this (roughly 7 steps)
[3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
feature/webaudio-csound
(base) stevenyi@stevens-MacBook-Pro csound % git bisect good
Bisecting: 42 revisions left to test after this (roughly 6 steps)
[2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
branch 'origin/develop' into feature/webaudio-csound-fs
(base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
Bisecting: 23 revisions left to test after this (roughly 5 steps)
[f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
from gesellkammer/develop
(base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
Bisecting: 10 revisions left to test after this (roughly 4 steps)
[6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
https://github.com/csound/csound into develop
(base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
sequ verbose case
(base) stevenyi@stevens-MacBook-Pro csound % git bisect good
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
(base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
(base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
(base) stevenyi@stevens-MacBook-Pro csound % git bisect good
2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit



On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>
> Do you have a minimal test? I can't reproduce this here with a simple UDO like
>
> opcode Test,a,kk
>  ka,kf xin
>  asig oscili ka,kf
>  xout asig
> endop
>
> instr 1
>  a1 Test p4, p5
>  out a1
> endin
>
> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>
>
> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>
> These are all names of UDOs; these print messages are breaking up
> audio and making live coding impossible. No idea yet where it's coming
> from.
>
> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>
>
> No sign of these messaes in my tree as far as i can tell
>
> Are the sbus_mix strings in your code? Dittp in_scale/
>
>
> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>
> I have not come across it, but I'll have a look
> tomorroe.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>
> *Warning*
>
> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>
> Hi All,
>
> I'm using the latest from the develop branch and there's some debug
> printing going on regarding UDO calls that happens even when -m0 is
> on. Does this ring a bell to anyone? I'm having difficulty finding the
> source of this (assume to be a printf somewhere).
>
> Thanks,
> Steven
>
> p.s. messages look like this:
>
> #i76    in_scale        -2      0       0
>       sbus_mix        0       al      ar      0
>       sbus_mix        0       al      ar      0
>       sbus_mix        0       al      ar      0
>       sbus_mix        0       al      ar      0
>       sbus_mix        0       al      ar      0
>       sbus_mix        0       al      ar      0
>       sbus_mix        0       al      ar      0
> #i76    in_scale        -2      0       0
> #i76    in_scale        -2      0       0
> #i76    in_scale        -2      0       0
> #i76    in_scale        -2      0       0
>
> Seems to happen when the UDOs are called
>
>

Here's an example that should cause problems. It exhibits different
behavior than when I test with livecoding (i.e., the sketch.orc gets
evaluated at runtime vs. included).  This one doesn't give the init
errors with UDOs I had but it does sound very glitchy/loud like all
the notes are overlapping. Again, if I roll back this project runs
fine.

On Mon, Jan 10, 2022 at 10:21 AM Steven Yi  wrote:
>
> I tried to make a minimal test but it also passed. I realized that -m0
> changed behavior and errors did not show up in the log. When I turned
> that off I got all the messages I didn't want plus the actual error
> messages I did want:
>
> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
> #i76    in_scale    -2    0    0
>    note aborted
> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
> initialised
>  from file livecode.orc (2), from file
> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
> 0    al    ar    0
>    note aborted
> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
> initialised
>  from file livecode.orc (2), from file
> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
> 0    al    ar    0
>    note aborted
>
> This code runs fine and has run fine for ages. It seems two things are
> happening:
>
> 1. Messages were removed from output that shouldn't have. I do not
> like that -m0 changed. What happened here? Either way it still printed
> the #i76 lines which made this very confusing.  It also probably
> breaks some host code of mine in Blue and other projects, but I really
> don't have the time to investigate.
> 2. Something changed with UDO calling. If I rollback to a commit a few
> weeks ago the project runs fine, so this is a new problem.
>
> I did a git bisect session yesterday but it lead to commit that I do
> not thing was the source of the problem:
>
> Your branch is up to date with 'origin/develop'.
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
> Bisecting: 179 revisions left to test after this (roughly 8 steps)
> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> Bisecting: 89 revisions left to test after this (roughly 7 steps)
> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
> feature/webaudio-csound
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> Bisecting: 42 revisions left to test after this (roughly 6 steps)
> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
> branch 'origin/develop' into feature/webaudio-csound-fs
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> Bisecting: 23 revisions left to test after this (roughly 5 steps)
> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
> from gesellkammer/develop
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> Bisecting: 10 revisions left to test after this (roughly 4 steps)
> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
> https://github.com/csound/csound into develop
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> Bisecting: 5 revisions left to test after this (roughly 3 steps)
> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
> sequ verbose case
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> Bisecting: 2 revisions left to test after this (roughly 2 steps)
> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> Bisecting: 0 revisions left to test after this (roughly 1 step)
> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>
>
>
> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
> >
> > Do you have a minimal test? I can't reproduce this here with a simple UDO like
> >
> > opcode Test,a,kk
> >  ka,kf xin
> >  asig oscili ka,kf
> >  xout asig
> > endop
> >
> > instr 1
> >  a1 Test p4, p5
> >  out a1
> > endin
> >
> > Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
> >
> >
> > On 10 Jan 2022, at 00:06, Steven Yi  wrote:
> >
> > These are all names of UDOs; these print messages are breaking up
> > audio and making live coding impossible. No idea yet where it's coming
> > from.
> >
> > On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
> >
> >
> > No sign of these messaes in my tree as far as i can tell
> >
> > Are the sbus_mix strings in your code? Dittp in_scale/
> >
> >
> > On Sun, 9 Jan 2022, Victor Lazzarini wrote:
> >
> > I have not come across it, but I'll have a look
> > tomorroe.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > On 9 Jan 2022, at 21:10, Steven Yi  wrote:
> >
> > *Warning*
> >
> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> >
> > Hi All,
> >
> > I'm using the latest from the develop branch and there's some debug
> > printing going on regarding UDO calls that happens even when -m0 is
> > on. Does this ring a bell to anyone? I'm having difficulty finding the
> > source of this (assume to be a printf somewhere).
> >
> > Thanks,
> > Steven
> >
> > p.s. messages look like this:
> >
> > #i76    in_scale        -2      0       0
> >       sbus_mix        0       al      ar      0
> >       sbus_mix        0       al      ar      0
> >       sbus_mix        0       al      ar      0
> >       sbus_mix        0       al      ar      0
> >       sbus_mix        0       al      ar      0
> >       sbus_mix        0       al      ar      0
> >       sbus_mix        0       al      ar      0
> > #i76    in_scale        -2      0       0
> > #i76    in_scale        -2      0       0
> > #i76    in_scale        -2      0       0
> > #i76    in_scale        -2      0       0
> >
> > Seems to happen when the UDOs are called
> >
> >
> >

Then we need to roll this back. What did you change in the template csd?

On Mon, Jan 10, 2022 at 10:38 AM Rory Walsh  wrote:
>
> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
>
> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
>>
>> I tried to make a minimal test but it also passed. I realized that -m0
>> changed behavior and errors did not show up in the log. When I turned
>> that off I got all the messages I didn't want plus the actual error
>> messages I did want:
>>
>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
>> #i76    in_scale    -2    0    0
>>    note aborted
>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>> initialised
>>  from file livecode.orc (2), from file
>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>> 0    al    ar    0
>>    note aborted
>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>> initialised
>>  from file livecode.orc (2), from file
>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>> 0    al    ar    0
>>    note aborted
>>
>> This code runs fine and has run fine for ages. It seems two things are
>> happening:
>>
>> 1. Messages were removed from output that shouldn't have. I do not
>> like that -m0 changed. What happened here? Either way it still printed
>> the #i76 lines which made this very confusing.  It also probably
>> breaks some host code of mine in Blue and other projects, but I really
>> don't have the time to investigate.
>> 2. Something changed with UDO calling. If I rollback to a commit a few
>> weeks ago the project runs fine, so this is a new problem.
>>
>> I did a git bisect session yesterday but it lead to commit that I do
>> not thing was the source of the problem:
>>
>> Your branch is up to date with 'origin/develop'.
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
>> feature/webaudio-csound
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
>> branch 'origin/develop' into feature/webaudio-csound-fs
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
>> from gesellkammer/develop
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
>> https://github.com/csound/csound into develop
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
>> sequ verbose case
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 0 revisions left to test after this (roughly 1 step)
>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>>
>>
>>
>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>> >
>> > Do you have a minimal test? I can't reproduce this here with a simple UDO like
>> >
>> > opcode Test,a,kk
>> >  ka,kf xin
>> >  asig oscili ka,kf
>> >  xout asig
>> > endop
>> >
>> > instr 1
>> >  a1 Test p4, p5
>> >  out a1
>> > endin
>> >
>> > Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>> >
>> >
>> > On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>> >
>> > These are all names of UDOs; these print messages are breaking up
>> > audio and making live coding impossible. No idea yet where it's coming
>> > from.
>> >
>> > On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>> >
>> >
>> > No sign of these messaes in my tree as far as i can tell
>> >
>> > Are the sbus_mix strings in your code? Dittp in_scale/
>> >
>> >
>> > On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>> >
>> > I have not come across it, but I'll have a look
>> > tomorroe.
>> >
>> > Prof. Victor Lazzarini
>> > Maynooth University
>> > Ireland
>> >
>> > On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>> >
>> > *Warning*
>> >
>> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> >
>> > Hi All,
>> >
>> > I'm using the latest from the develop branch and there's some debug
>> > printing going on regarding UDO calls that happens even when -m0 is
>> > on. Does this ring a bell to anyone? I'm having difficulty finding the
>> > source of this (assume to be a printf somewhere).
>> >
>> > Thanks,
>> > Steven
>> >
>> > p.s. messages look like this:
>> >
>> > #i76    in_scale        -2      0       0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> > #i76    in_scale        -2      0       0
>> > #i76    in_scale        -2      0       0
>> > #i76    in_scale        -2      0       0
>> > #i76    in_scale        -2      0       0
>> >
>> > Seems to happen when the UDOs are called
>> >
>> >

Not sure how this relates to the bisect action but there was a PR 

We need to discuss it on Thursday. It was requested on the list and implemented then.

I outlined all changes here and no one disagreed then.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 10 Jan 2022, at 15:41, Steven Yi  wrote:
> 
> Then we need to roll this back. What did you change in the template csd?
> 
>> On Mon, Jan 10, 2022 at 10:38 AM Rory Walsh  wrote:
>> 
>> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
>> 
>>> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
>>> 
>>> I tried to make a minimal test but it also passed. I realized that -m0
>>> changed behavior and errors did not show up in the log. When I turned
>>> that off I got all the messages I didn't want plus the actual error
>>> messages I did want:
>>> 
>>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
>>> #i76    in_scale    -2    0    0
>>>   note aborted
>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>> initialised
>>> from file livecode.orc (2), from file
>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>> 0    al    ar    0
>>>   note aborted
>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>> initialised
>>> from file livecode.orc (2), from file
>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>> 0    al    ar    0
>>>   note aborted
>>> 
>>> This code runs fine and has run fine for ages. It seems two things are
>>> happening:
>>> 
>>> 1. Messages were removed from output that shouldn't have. I do not
>>> like that -m0 changed. What happened here? Either way it still printed
>>> the #i76 lines which made this very confusing.  It also probably
>>> breaks some host code of mine in Blue and other projects, but I really
>>> don't have the time to investigate.
>>> 2. Something changed with UDO calling. If I rollback to a commit a few
>>> weeks ago the project runs fine, so this is a new problem.
>>> 
>>> I did a git bisect session yesterday but it lead to commit that I do
>>> not thing was the source of the problem:
>>> 
>>> Your branch is up to date with 'origin/develop'.
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
>>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
>>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
>>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
>>> feature/webaudio-csound
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
>>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
>>> branch 'origin/develop' into feature/webaudio-csound-fs
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
>>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
>>> from gesellkammer/develop
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
>>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C08bcbccd287f4cac7e5808d9d44fba20%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637774261162838345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IF0C4o9c58%2F71WDpy0QyllQogH7rsa6Q70hiD40EeTc%3D&reserved=0 into develop
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
>>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
>>> sequ verbose case
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
>>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 0 revisions left to test after this (roughly 1 step)
>>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>>> 
>>> 
>>> 
>>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>>>> 
>>>> Do you have a minimal test? I can't reproduce this here with a simple UDO like
>>>> 
>>>> opcode Test,a,kk
>>>> ka,kf xin
>>>> asig oscili ka,kf
>>>> xout asig
>>>> endop
>>>> 
>>>> instr 1
>>>> a1 Test p4, p5
>>>> out a1
>>>> endin
>>>> 
>>>> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>>>> 
>>>> 
>>>> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>>>> 
>>>> These are all names of UDOs; these print messages are breaking up
>>>> audio and making live coding impossible. No idea yet where it's coming
>>>> from.
>>>> 
>>>> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>>>> 
>>>> 
>>>> No sign of these messaes in my tree as far as i can tell
>>>> 
>>>> Are the sbus_mix strings in your code? Dittp in_scale/
>>>> 
>>>> 
>>>> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>>>> 
>>>> I have not come across it, but I'll have a look
>>>> tomorroe.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>>>> 
>>>> *Warning*
>>>> 
>>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>> 
>>>> Hi All,
>>>> 
>>>> I'm using the latest from the develop branch and there's some debug
>>>> printing going on regarding UDO calls that happens even when -m0 is
>>>> on. Does this ring a bell to anyone? I'm having difficulty finding the
>>>> source of this (assume to be a printf somewhere).
>>>> 
>>>> Thanks,
>>>> Steven
>>>> 
>>>> p.s. messages look like this:
>>>> 
>>>> #i76    in_scale        -2      0       0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>> #i76    in_scale        -2      0       0
>>>> #i76    in_scale        -2      0       0
>>>> #i76    in_scale        -2      0       0
>>>> #i76    in_scale        -2      0       0
>>>> 
>>>> Seems to happen when 

I'm fine with having an ability to shut down all messages, but not if
it breaks backwards compatibility. Let's find a different flag to use
(and also find out why that one line was still being printed).

Anyone have leads on the new init-errors? Related to schedule maybe?
Or some change in runtime code evaluation?

On Mon, Jan 10, 2022 at 11:05 AM Victor Lazzarini
 wrote:
>
> The change was discussed here. I had requests for this and I explained what I did.
>
> I did quite a bit of work on this earlier on, because to be honest it was a real mess. At least things are more regular now.
>
> We can discuss the level of messaging on Thursday too. I have no fixed idea but I quite like the ability to shut down all messages that we have now.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> On 10 Jan 2022, at 15:38, Rory Walsh  wrote:
>
> 
> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
>
> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
>>
>> I tried to make a minimal test but it also passed. I realized that -m0
>> changed behavior and errors did not show up in the log. When I turned
>> that off I got all the messages I didn't want plus the actual error
>> messages I did want:
>>
>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
>> #i76    in_scale    -2    0    0
>>    note aborted
>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>> initialised
>>  from file livecode.orc (2), from file
>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>> 0    al    ar    0
>>    note aborted
>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>> initialised
>>  from file livecode.orc (2), from file
>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>> 0    al    ar    0
>>    note aborted
>>
>> This code runs fine and has run fine for ages. It seems two things are
>> happening:
>>
>> 1. Messages were removed from output that shouldn't have. I do not
>> like that -m0 changed. What happened here? Either way it still printed
>> the #i76 lines which made this very confusing.  It also probably
>> breaks some host code of mine in Blue and other projects, but I really
>> don't have the time to investigate.
>> 2. Something changed with UDO calling. If I rollback to a commit a few
>> weeks ago the project runs fine, so this is a new problem.
>>
>> I did a git bisect session yesterday but it lead to commit that I do
>> not thing was the source of the problem:
>>
>> Your branch is up to date with 'origin/develop'.
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
>> feature/webaudio-csound
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
>> branch 'origin/develop' into feature/webaudio-csound-fs
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
>> from gesellkammer/develop
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
>> https://github.com/csound/csound into develop
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
>> sequ verbose case
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 0 revisions left to test after this (roughly 1 step)
>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>>
>>
>>
>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>> >
>> > Do you have a minimal test? I can't reproduce this here with a simple UDO like
>> >
>> > opcode Test,a,kk
>> >  ka,kf xin
>> >  asig oscili ka,kf
>> >  xout asig
>> > endop
>> >
>> > instr 1
>> >  a1 Test p4, p5
>> >  out a1
>> > endin
>> >
>> > Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>> >
>> >
>> > On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>> >
>> > These are all names of UDOs; these print messages are breaking up
>> > audio and making live coding impossible. No idea yet where it's coming
>> > from.
>> >
>> > On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>> >
>> >
>> > No sign of these messaes in my tree as far as i can tell
>> >
>> > Are the sbus_mix strings in your code? Dittp in_scale/
>> >
>> >
>> > On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>> >
>> > I have not come across it, but I'll have a look
>> > tomorroe.
>> >
>> > Prof. Victor Lazzarini
>> > Maynooth University
>> > Ireland
>> >
>> > On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>> >
>> > *Warning*
>> >
>> > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>> >
>> > Hi All,
>> >
>> > I'm using the latest from the develop branch and there's some debug
>> > printing going on regarding UDO calls that happens even when -m0 is
>> > on. Does this ring a bell to anyone? I'm having difficulty finding the
>> > source of this (assume to be a printf somewhere).
>> >
>> > Thanks,
>> > Steven
>> >
>> > p.s. messages look like this:
>> >
>> > #i76    in_scale        -2      0       0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> >       sbus_mix        0       al      ar      0
>> > #i76    in_scale        -2      0       0
>> > #i76    in_scale        -2      0       0
>> > #i76    in_scale        -2      0       0
>> > #i76    in_scale        -2      0       0
>> >
>> > Seems to happen when the UDOs are called
>> >
>> >

I don't know what these init errors are, I don't think I made any changes to that part of the code recently.

The fact that that line is still printed shows that I did not complete the reorganisation of logging, something is still in the confused state as before.

As far as I can recall, with my changes, it should be very easy to vary the logging level in terms of what should be printed. Rolling back to the chaotic state it was before it is not an option.

I still think that 0 should suppress all messages. We should make better use of the message level control instead of introducing more flags.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 10 Jan 2022, at 16:09, Steven Yi  wrote:
> 
> I'm fine with having an ability to shut down all messages, but not if
> it breaks backwards compatibility. Let's find a different flag to use
> (and also find out why that one line was still being printed).
> 
> Anyone have leads on the new init-errors? Related to schedule maybe?
> Or some change in runtime code evaluation?
> 
>> On Mon, Jan 10, 2022 at 11:05 AM Victor Lazzarini
>>  wrote:
>> 
>> The change was discussed here. I had requests for this and I explained what I did.
>> 
>> I did quite a bit of work on this earlier on, because to be honest it was a real mess. At least things are more regular now.
>> 
>> We can discuss the level of messaging on Thursday too. I have no fixed idea but I quite like the ability to shut down all messages that we have now.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>> On 10 Jan 2022, at 15:38, Rory Walsh  wrote:
>> 
>> 
>> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
>> 
>>> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
>>> 
>>> I tried to make a minimal test but it also passed. I realized that -m0
>>> changed behavior and errors did not show up in the log. When I turned
>>> that off I got all the messages I didn't want plus the actual error
>>> messages I did want:
>>> 
>>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
>>> #i76    in_scale    -2    0    0
>>>   note aborted
>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>> initialised
>>> from file livecode.orc (2), from file
>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>> 0    al    ar    0
>>>   note aborted
>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>> initialised
>>> from file livecode.orc (2), from file
>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>> 0    al    ar    0
>>>   note aborted
>>> 
>>> This code runs fine and has run fine for ages. It seems two things are
>>> happening:
>>> 
>>> 1. Messages were removed from output that shouldn't have. I do not
>>> like that -m0 changed. What happened here? Either way it still printed
>>> the #i76 lines which made this very confusing.  It also probably
>>> breaks some host code of mine in Blue and other projects, but I really
>>> don't have the time to investigate.
>>> 2. Something changed with UDO calling. If I rollback to a commit a few
>>> weeks ago the project runs fine, so this is a new problem.
>>> 
>>> I did a git bisect session yesterday but it lead to commit that I do
>>> not thing was the source of the problem:
>>> 
>>> Your branch is up to date with 'origin/develop'.
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
>>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
>>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
>>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
>>> feature/webaudio-csound
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
>>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
>>> branch 'origin/develop' into feature/webaudio-csound-fs
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
>>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
>>> from gesellkammer/develop
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
>>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C3e39913f5fbe4b0947c808d9d45394d4%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637774277710238050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=K3FRVlxlmqJqu5NkSJYW%2BceVZOiiulOZrz3J6uv%2FTvg%3D&reserved=0 into develop
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
>>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
>>> sequ verbose case
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
>>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 0 revisions left to test after this (roughly 1 step)
>>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>>> 
>>> 
>>> 
>>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>>>> 
>>>> Do you have a minimal test? I can't reproduce this here with a simple UDO like
>>>> 
>>>> opcode Test,a,kk
>>>> ka,kf xin
>>>> asig oscili ka,kf
>>>> xout asig
>>>> endop
>>>> 
>>>> instr 1
>>>> a1 Test p4, p5
>>>> out a1
>>>> endin
>>>> 
>>>> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>>>> 
>>>> 
>>>> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>>>> 
>>>> These are all names of UDOs; these print messages are breaking up
>>>> audio and making live coding impossible. No idea yet where it's coming
>>>> from.
>>>> 
>>>> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>>>> 
>>>> 
>>>> No sign of these messaes in my tree as far as i can tell
>>>> 
>>>> Are the sbus_mix strings in your code? Dittp in_scale/
>>>> 
>>>> 
>>>> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>>>> 
>>>> I have not come across it, but I'll have a look
>>>> tomorroe.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>>>> 
>>>> *Warning*
>>>> 
>>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>> 
>>>> Hi All,
>>>> 
>>>> I'm using the latest from the develop branch and there's some debug
>>>> printing going on regarding UDO calls that happens even when -m0 is
>>>> on. Does this ring a bell to anyone? I'm having difficulty finding the
>>>> source of this (assume to be a printf somewhere).
>>>> 
>>>> Thanks,
>>>> Steven
>>>> 
>>>> p.s. messages look like this:
>>>> 
>>>> #i76    in_scale        -2      0       0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>>      sbus_mix        0       al      ar      0
>>>> #i76    in_scale        -2      0       0
>>>> #i76    in_scale        -2      0       0
>>>> #i76    in_scale        -2      0       0
>>>> #i76    in_scale        -2      0       0
>>>> 
>>>> Seems to happen when the UDOs are called
>>>> 
>>>> 
>>>>

But again this has broken backwards compatibility. I don't see how to
get the messages that I used to get that were relevant to me and that
I relied upon (having just errors and user-defined print statements).
I absolutely can not use this for live coding if the above is not
supported. BTW the latest manual still has:


-m NUM, --messagelevel=NUM

Message level for standard (terminal) output. Takes the sum of any of
the following values:

1 = note amplitude messages

2 = samples out of range message

4 = warning messages

128 = print benchmark information

1024 = suppress deprecated messages

And exactly one of these to select note amplitude format:

0 = raw amplitudes, no colours

32 = dB, no colors

64 = dB, out of range highlighted with red

96 = dB, all colors

256 = raw, out of range highlighted with red

512 = raw, all colours

The default is 135 (128+4+2+1), which means all messages, raw
amplitude values, and printing elapsed time at the end of performance.
The coloring of raw amplitudes was introduced in version 5.04.
Suppression of deprecated messages new in 6.14.

On Mon, Jan 10, 2022 at 11:16 AM Victor Lazzarini
 wrote:
>
> I don't know what these init errors are, I don't think I made any changes to that part of the code recently.
>
> The fact that that line is still printed shows that I did not complete the reorganisation of logging, something is still in the confused state as before.
>
> As far as I can recall, with my changes, it should be very easy to vary the logging level in terms of what should be printed. Rolling back to the chaotic state it was before it is not an option.
>
> I still think that 0 should suppress all messages. We should make better use of the message level control instead of introducing more flags.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 10 Jan 2022, at 16:09, Steven Yi  wrote:
> >
> > I'm fine with having an ability to shut down all messages, but not if
> > it breaks backwards compatibility. Let's find a different flag to use
> > (and also find out why that one line was still being printed).
> >
> > Anyone have leads on the new init-errors? Related to schedule maybe?
> > Or some change in runtime code evaluation?
> >
> >> On Mon, Jan 10, 2022 at 11:05 AM Victor Lazzarini
> >>  wrote:
> >>
> >> The change was discussed here. I had requests for this and I explained what I did.
> >>
> >> I did quite a bit of work on this earlier on, because to be honest it was a real mess. At least things are more regular now.
> >>
> >> We can discuss the level of messaging on Thursday too. I have no fixed idea but I quite like the ability to shut down all messages that we have now.
> >>
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >>
> >> On 10 Jan 2022, at 15:38, Rory Walsh  wrote:
> >>
> >> 
> >> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
> >>
> >>> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
> >>>
> >>> I tried to make a minimal test but it also passed. I realized that -m0
> >>> changed behavior and errors did not show up in the log. When I turned
> >>> that off I got all the messages I didn't want plus the actual error
> >>> messages I did want:
> >>>
> >>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
> >>> #i76    in_scale    -2    0    0
> >>>   note aborted
> >>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
> >>> initialised
> >>> from file livecode.orc (2), from file
> >>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
> >>> 0    al    ar    0
> >>>   note aborted
> >>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
> >>> initialised
> >>> from file livecode.orc (2), from file
> >>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
> >>> 0    al    ar    0
> >>>   note aborted
> >>>
> >>> This code runs fine and has run fine for ages. It seems two things are
> >>> happening:
> >>>
> >>> 1. Messages were removed from output that shouldn't have. I do not
> >>> like that -m0 changed. What happened here? Either way it still printed
> >>> the #i76 lines which made this very confusing.  It also probably
> >>> breaks some host code of mine in Blue and other projects, but I really
> >>> don't have the time to investigate.
> >>> 2. Something changed with UDO calling. If I rollback to a commit a few
> >>> weeks ago the project runs fine, so this is a new problem.
> >>>
> >>> I did a git bisect session yesterday but it lead to commit that I do
> >>> not thing was the source of the problem:
> >>>
> >>> Your branch is up to date with 'origin/develop'.
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
> >>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
> >>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
> >>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
> >>> feature/webaudio-csound
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
> >>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
> >>> branch 'origin/develop' into feature/webaudio-csound-fs
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
> >>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
> >>> from gesellkammer/develop
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
> >>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
> >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C3e39913f5fbe4b0947c808d9d45394d4%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637774277710238050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=K3FRVlxlmqJqu5NkSJYW%2BceVZOiiulOZrz3J6uv%2FTvg%3D&reserved=0 into develop
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
> >>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
> >>> sequ verbose case
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
> >>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>> Bisecting: 0 revisions left to test after this (roughly 1 step)
> >>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> >>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
> >>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
> >>>
> >>>
> >>>
> >>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
> >>>>
> >>>> Do you have a minimal test? I can't reproduce this here with a simple UDO like
> >>>>
> >>>> opcode Test,a,kk
> >>>> ka,kf xin
> >>>> asig oscili ka,kf
> >>>> xout asig
> >>>> endop
> >>>>
> >>>> instr 1
> >>>> a1 Test p4, p5
> >>>> out a1
> >>>> endin
> >>>>
> >>>> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
> >>>>
> >>>>
> >>>> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
> >>>>
> >>>> These are all names of UDOs; these print messages are breaking up
> >>>> audio and making live coding impossible. No idea yet where it's coming
> >>>> from.
> >>>>
> >>>> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
> >>>>
> >>>>
> >>>> No sign of these messaes in my tree as far as i can tell
> >>>>
> >>>> Are the sbus_mix strings in your code? Dittp in_scale/
> >>>>
> >>>>
> >>>> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
> >>>>
> >>>> I have not come across it, but I'll have a look
> >>>> tomorroe.
> >>>>
> >>>> Prof. Victor Lazzarini
> >>>> Maynooth University
> >>>> Ireland
> >>>>
> >>>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
> >>>>
> >>>> *Warning*
> >>>>
> >>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> >>>>
> >>>> Hi All,
> >>>>
> >>>> I'm using the latest from the develop branch and there's some debug
> >>>> printing going on regarding UDO calls that happens even when -m0 is
> >>>> on. Does this ring a bell to anyone? I'm having difficulty finding the
> >>>> source of this (assume to be a printf somewhere).
> >>>>
> >>>> Thanks,
> >>>> Steven
> >>>>
> >>>> p.s. messages look like this:
> >>>>
> >>>> #i76    in_scale        -2      0       0
> >>>>      sbus_mix        0       al      ar      0
> >>>>      sbus_mix        0       al      ar      0
> >>>>      sbus_mix        0       al      ar      0
> >>>>      sbus_mix        0       al      ar      0
> >>>>      sbus_mix        0       al      ar      0
> >>>>      sbus_mix        0       al      ar      0
> >>>>      sbus_mix        0       al      ar      0
> >>>> #i76    in_scale        -2      0       0
> >>>> #i76    in_scale        -2      0       0
> >>>> #i76    in_scale        -2      0       0
> >>>> #i76    in_scale        -2      0       0
> >>>>
> >>>> Seems to happen when the UDOs are called
> >>>>
> >>>>

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 10 Jan 2022, at 17:10, Steven Yi  wrote:
> 
> But again this has broken backwards compatibility. I don't see how to
> get the messages that I used to get that were relevant to me and that
> I relied upon (having just errors and user-defined print statements).
> I absolutely can not use this for live coding if the above is not
> supported. BTW the latest manual still has:
> 
> 
> -m NUM, --messagelevel=NUM
> 
> Message level for standard (terminal) output. Takes the sum of any of
> the following values:
> 
> 1 = note amplitude messages
> 
> 2 = samples out of range message
> 
> 4 = warning messages
> 
> 128 = print benchmark information
> 
> 1024 = suppress deprecated messages
> 
> And exactly one of these to select note amplitude format:
> 
> 0 = raw amplitudes, no colours
> 
> 32 = dB, no colors
> 
> 64 = dB, out of range highlighted with red
> 
> 96 = dB, all colors
> 
> 256 = raw, out of range highlighted with red
> 
> 512 = raw, all colours
> 
> The default is 135 (128+4+2+1), which means all messages, raw
> amplitude values, and printing elapsed time at the end of performance.
> The coloring of raw amplitudes was introduced in version 5.04.
> Suppression of deprecated messages new in 6.14.
> 
>> On Mon, Jan 10, 2022 at 11:16 AM Victor Lazzarini
>>  wrote:
>> 
>> I don't know what these init errors are, I don't think I made any changes to that part of the code recently.
>> 
>> The fact that that line is still printed shows that I did not complete the reorganisation of logging, something is still in the confused state as before.
>> 
>> As far as I can recall, with my changes, it should be very easy to vary the logging level in terms of what should be printed. Rolling back to the chaotic state it was before it is not an option.
>> 
>> I still think that 0 should suppress all messages. We should make better use of the message level control instead of introducing more flags.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>>> On 10 Jan 2022, at 16:09, Steven Yi  wrote:
>>> 
>>> I'm fine with having an ability to shut down all messages, but not if
>>> it breaks backwards compatibility. Let's find a different flag to use
>>> (and also find out why that one line was still being printed).
>>> 
>>> Anyone have leads on the new init-errors? Related to schedule maybe?
>>> Or some change in runtime code evaluation?
>>> 
>>>> On Mon, Jan 10, 2022 at 11:05 AM Victor Lazzarini
>>>>  wrote:
>>>> 
>>>> The change was discussed here. I had requests for this and I explained what I did.
>>>> 
>>>> I did quite a bit of work on this earlier on, because to be honest it was a real mess. At least things are more regular now.
>>>> 
>>>> We can discuss the level of messaging on Thursday too. I have no fixed idea but I quite like the ability to shut down all messages that we have now.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>> On 10 Jan 2022, at 15:38, Rory Walsh  wrote:
>>>> 
>>>> 
>>>> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
>>>> 
>>>>> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
>>>>> 
>>>>> I tried to make a minimal test but it also passed. I realized that -m0
>>>>> changed behavior and errors did not show up in the log. When I turned
>>>>> that off I got all the messages I didn't want plus the actual error
>>>>> messages I did want:
>>>>> 
>>>>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
>>>>> #i76    in_scale    -2    0    0
>>>>>  note aborted
>>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>>>> initialised
>>>>> from file livecode.orc (2), from file
>>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>>>> 0    al    ar    0
>>>>>  note aborted
>>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>>>> initialised
>>>>> from file livecode.orc (2), from file
>>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>>>> 0    al    ar    0
>>>>>  note aborted
>>>>> 
>>>>> This code runs fine and has run fine for ages. It seems two things are
>>>>> happening:
>>>>> 
>>>>> 1. Messages were removed from output that shouldn't have. I do not
>>>>> like that -m0 changed. What happened here? Either way it still printed
>>>>> the #i76 lines which made this very confusing.  It also probably
>>>>> breaks some host code of mine in Blue and other projects, but I really
>>>>> don't have the time to investigate.
>>>>> 2. Something changed with UDO calling. If I rollback to a commit a few
>>>>> weeks ago the project runs fine, so this is a new problem.
>>>>> 
>>>>> I did a git bisect session yesterday but it lead to commit that I do
>>>>> not thing was the source of the problem:
>>>>> 
>>>>> Your branch is up to date with 'origin/develop'.
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
>>>>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
>>>>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
>>>>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
>>>>> feature/webaudio-csound
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
>>>>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
>>>>> branch 'origin/develop' into feature/webaudio-csound-fs
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
>>>>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
>>>>> from gesellkammer/develop
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
>>>>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C761c10283a4848c14dea08d9d45bfec9%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637774314473042070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Dcc9kTeGJpXsSzZNoZ2zO%2FRWKiBjBMPAvi82RWQDMMg%3D&reserved=0 into develop
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
>>>>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
>>>>> sequ verbose case
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
>>>>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 0 revisions left to test after this (roughly 1 step)
>>>>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>>>>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Do you have a minimal test? I can't reproduce this here with a simple UDO like
>>>>>> 
>>>>>> opcode Test,a,kk
>>>>>> ka,kf xin
>>>>>> asig oscili ka,kf
>>>>>> xout asig
>>>>>> endop
>>>>>> 
>>>>>> instr 1
>>>>>> a1 Test p4, p5
>>>>>> out a1
>>>>>> endin
>>>>>> 
>>>>>> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>>>>>> 
>>>>>> 
>>>>>> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>>>>>> 
>>>>>> These are all names of UDOs; these print messages are breaking up
>>>>>> audio and making live coding impossible. No idea yet where it's coming
>>>>>> from.
>>>>>> 
>>>>>> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>>>>>> 
>>>>>> 
>>>>>> No sign of these messaes in my tree as far as i can tell
>>>>>> 
>>>>>> Are the sbus_mix strings in your code? Dittp in_scale/
>>>>>> 
>>>>>> 
>>>>>> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>>>>>> 
>>>>>> I have not come across it, but I'll have a look
>>>>>> tomorroe.
>>>>>> 
>>>>>> Prof. Victor Lazzarini
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>>>>>> 
>>>>>> *Warning*
>>>>>> 
>>>>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> I'm using the latest from the develop branch and there's some debug
>>>>>> printing going on regarding UDO calls that happens even when -m0 is
>>>>>> on. Does this ring a bell to anyone? I'm having difficulty finding the
>>>>>> source of this (assume to be a printf somewhere).
>>>>>> 
>>>>>> Thanks,
>>>>>> Steven
>>>>>> 
>>>>>> p.s. messages look like this:
>>>>>> 
>>>>>> #i76    in_scale        -2      0       0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> 
>>>>>> Seems to happen when the UDOs are called
>>>>>> 
>>>>>> 
>>

So the difference is that with -m0 we don't display the raw amplitudes. We could bring that back, but I fail to see it is much use.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 10 Jan 2022, at 17:10, Steven Yi  wrote:
> 
> But again this has broken backwards compatibility. I don't see how to
> get the messages that I used to get that were relevant to me and that
> I relied upon (having just errors and user-defined print statements).
> I absolutely can not use this for live coding if the above is not
> supported. BTW the latest manual still has:
> 
> 
> -m NUM, --messagelevel=NUM
> 
> Message level for standard (terminal) output. Takes the sum of any of
> the following values:
> 
> 1 = note amplitude messages
> 
> 2 = samples out of range message
> 
> 4 = warning messages
> 
> 128 = print benchmark information
> 
> 1024 = suppress deprecated messages
> 
> And exactly one of these to select note amplitude format:
> 
> 0 = raw amplitudes, no colours
> 
> 32 = dB, no colors
> 
> 64 = dB, out of range highlighted with red
> 
> 96 = dB, all colors
> 
> 256 = raw, out of range highlighted with red
> 
> 512 = raw, all colours
> 
> The default is 135 (128+4+2+1), which means all messages, raw
> amplitude values, and printing elapsed time at the end of performance.
> The coloring of raw amplitudes was introduced in version 5.04.
> Suppression of deprecated messages new in 6.14.
> 
>> On Mon, Jan 10, 2022 at 11:16 AM Victor Lazzarini
>>  wrote:
>> 
>> I don't know what these init errors are, I don't think I made any changes to that part of the code recently.
>> 
>> The fact that that line is still printed shows that I did not complete the reorganisation of logging, something is still in the confused state as before.
>> 
>> As far as I can recall, with my changes, it should be very easy to vary the logging level in terms of what should be printed. Rolling back to the chaotic state it was before it is not an option.
>> 
>> I still think that 0 should suppress all messages. We should make better use of the message level control instead of introducing more flags.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>>> On 10 Jan 2022, at 16:09, Steven Yi  wrote:
>>> 
>>> I'm fine with having an ability to shut down all messages, but not if
>>> it breaks backwards compatibility. Let's find a different flag to use
>>> (and also find out why that one line was still being printed).
>>> 
>>> Anyone have leads on the new init-errors? Related to schedule maybe?
>>> Or some change in runtime code evaluation?
>>> 
>>>> On Mon, Jan 10, 2022 at 11:05 AM Victor Lazzarini
>>>>  wrote:
>>>> 
>>>> The change was discussed here. I had requests for this and I explained what I did.
>>>> 
>>>> I did quite a bit of work on this earlier on, because to be honest it was a real mess. At least things are more regular now.
>>>> 
>>>> We can discuss the level of messaging on Thursday too. I have no fixed idea but I quite like the ability to shut down all messages that we have now.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>> On 10 Jan 2022, at 15:38, Rory Walsh  wrote:
>>>> 
>>>> 
>>>> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
>>>> 
>>>>> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
>>>>> 
>>>>> I tried to make a minimal test but it also passed. I realized that -m0
>>>>> changed behavior and errors did not show up in the log. When I turned
>>>>> that off I got all the messages I didn't want plus the actual error
>>>>> messages I did want:
>>>>> 
>>>>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
>>>>> #i76    in_scale    -2    0    0
>>>>>  note aborted
>>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>>>> initialised
>>>>> from file livecode.orc (2), from file
>>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>>>> 0    al    ar    0
>>>>>  note aborted
>>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>>>> initialised
>>>>> from file livecode.orc (2), from file
>>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>>>> 0    al    ar    0
>>>>>  note aborted
>>>>> 
>>>>> This code runs fine and has run fine for ages. It seems two things are
>>>>> happening:
>>>>> 
>>>>> 1. Messages were removed from output that shouldn't have. I do not
>>>>> like that -m0 changed. What happened here? Either way it still printed
>>>>> the #i76 lines which made this very confusing.  It also probably
>>>>> breaks some host code of mine in Blue and other projects, but I really
>>>>> don't have the time to investigate.
>>>>> 2. Something changed with UDO calling. If I rollback to a commit a few
>>>>> weeks ago the project runs fine, so this is a new problem.
>>>>> 
>>>>> I did a git bisect session yesterday but it lead to commit that I do
>>>>> not thing was the source of the problem:
>>>>> 
>>>>> Your branch is up to date with 'origin/develop'.
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
>>>>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
>>>>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
>>>>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
>>>>> feature/webaudio-csound
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
>>>>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
>>>>> branch 'origin/develop' into feature/webaudio-csound-fs
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
>>>>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
>>>>> from gesellkammer/develop
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
>>>>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C761c10283a4848c14dea08d9d45bfec9%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637774314473042070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Dcc9kTeGJpXsSzZNoZ2zO%2FRWKiBjBMPAvi82RWQDMMg%3D&reserved=0 into develop
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
>>>>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
>>>>> sequ verbose case
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
>>>>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 0 revisions left to test after this (roughly 1 step)
>>>>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>>>>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>>>>>> 
>>>>>> Do you have a minimal test? I can't reproduce this here with a simple UDO like
>>>>>> 
>>>>>> opcode Test,a,kk
>>>>>> ka,kf xin
>>>>>> asig oscili ka,kf
>>>>>> xout asig
>>>>>> endop
>>>>>> 
>>>>>> instr 1
>>>>>> a1 Test p4, p5
>>>>>> out a1
>>>>>> endin
>>>>>> 
>>>>>> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>>>>>> 
>>>>>> 
>>>>>> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>>>>>> 
>>>>>> These are all names of UDOs; these print messages are breaking up
>>>>>> audio and making live coding impossible. No idea yet where it's coming
>>>>>> from.
>>>>>> 
>>>>>> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>>>>>> 
>>>>>> 
>>>>>> No sign of these messaes in my tree as far as i can tell
>>>>>> 
>>>>>> Are the sbus_mix strings in your code? Dittp in_scale/
>>>>>> 
>>>>>> 
>>>>>> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>>>>>> 
>>>>>> I have not come across it, but I'll have a look
>>>>>> tomorroe.
>>>>>> 
>>>>>> Prof. Victor Lazzarini
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>>>>>> 
>>>>>> *Warning*
>>>>>> 
>>>>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> I'm using the latest from the develop branch and there's some debug
>>>>>> printing going on regarding UDO calls that happens even when -m0 is
>>>>>> on. Does this ring a bell to anyone? I'm having difficulty finding the
>>>>>> source of this (assume to be a printf somewhere).
>>>>>> 
>>>>>> Thanks,
>>>>>> Steven
>>>>>> 
>>>>>> p.s. messages look like this:
>>>>>> 
>>>>>> #i76    in_scale        -2      0       0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>>     sbus_mix        0       al      ar      0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> #i76    in_scale        -2      0       0
>>>>>> 
>>>>>> Seems to happen when the UDOs are called
>>>

For live cdng you probably want -m 1024 to suppress messages 

With -m0 I used to get error messages but not now. It did not show
raw-amplitudes.

On Mon, Jan 10, 2022 at 12:36 PM Victor Lazzarini
 wrote:
>
> So the difference is that with -m0 we don't display the raw amplitudes. We could bring that back, but I fail to see it is much use.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
> > On 10 Jan 2022, at 17:10, Steven Yi  wrote:
> >
> > But again this has broken backwards compatibility. I don't see how to
> > get the messages that I used to get that were relevant to me and that
> > I relied upon (having just errors and user-defined print statements).
> > I absolutely can not use this for live coding if the above is not
> > supported. BTW the latest manual still has:
> >
> >
> > -m NUM, --messagelevel=NUM
> >
> > Message level for standard (terminal) output. Takes the sum of any of
> > the following values:
> >
> > 1 = note amplitude messages
> >
> > 2 = samples out of range message
> >
> > 4 = warning messages
> >
> > 128 = print benchmark information
> >
> > 1024 = suppress deprecated messages
> >
> > And exactly one of these to select note amplitude format:
> >
> > 0 = raw amplitudes, no colours
> >
> > 32 = dB, no colors
> >
> > 64 = dB, out of range highlighted with red
> >
> > 96 = dB, all colors
> >
> > 256 = raw, out of range highlighted with red
> >
> > 512 = raw, all colours
> >
> > The default is 135 (128+4+2+1), which means all messages, raw
> > amplitude values, and printing elapsed time at the end of performance.
> > The coloring of raw amplitudes was introduced in version 5.04.
> > Suppression of deprecated messages new in 6.14.
> >
> >> On Mon, Jan 10, 2022 at 11:16 AM Victor Lazzarini
> >>  wrote:
> >>
> >> I don't know what these init errors are, I don't think I made any changes to that part of the code recently.
> >>
> >> The fact that that line is still printed shows that I did not complete the reorganisation of logging, something is still in the confused state as before.
> >>
> >> As far as I can recall, with my changes, it should be very easy to vary the logging level in terms of what should be printed. Rolling back to the chaotic state it was before it is not an option.
> >>
> >> I still think that 0 should suppress all messages. We should make better use of the message level control instead of introducing more flags.
> >>
> >> Prof. Victor Lazzarini
> >> Maynooth University
> >> Ireland
> >>
> >>>> On 10 Jan 2022, at 16:09, Steven Yi  wrote:
> >>>
> >>> I'm fine with having an ability to shut down all messages, but not if
> >>> it breaks backwards compatibility. Let's find a different flag to use
> >>> (and also find out why that one line was still being printed).
> >>>
> >>> Anyone have leads on the new init-errors? Related to schedule maybe?
> >>> Or some change in runtime code evaluation?
> >>>
> >>>> On Mon, Jan 10, 2022 at 11:05 AM Victor Lazzarini
> >>>>  wrote:
> >>>>
> >>>> The change was discussed here. I had requests for this and I explained what I did.
> >>>>
> >>>> I did quite a bit of work on this earlier on, because to be honest it was a real mess. At least things are more regular now.
> >>>>
> >>>> We can discuss the level of messaging on Thursday too. I have no fixed idea but I quite like the ability to shut down all messages that we have now.
> >>>>
> >>>> Prof. Victor Lazzarini
> >>>> Maynooth University
> >>>> Ireland
> >>>>
> >>>> On 10 Jan 2022, at 15:38, Rory Walsh  wrote:
> >>>>
> >>>> 
> >>>> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
> >>>>
> >>>>> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
> >>>>>
> >>>>> I tried to make a minimal test but it also passed. I realized that -m0
> >>>>> changed behavior and errors did not show up in the log. When I turned
> >>>>> that off I got all the messages I didn't want plus the actual error
> >>>>> messages I did want:
> >>>>>
> >>>>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
> >>>>> #i76    in_scale    -2    0    0
> >>>>>  note aborted
> >>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
> >>>>> initialised
> >>>>> from file livecode.orc (2), from file
> >>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
> >>>>> 0    al    ar    0
> >>>>>  note aborted
> >>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
> >>>>> initialised
> >>>>> from file livecode.orc (2), from file
> >>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
> >>>>> 0    al    ar    0
> >>>>>  note aborted
> >>>>>
> >>>>> This code runs fine and has run fine for ages. It seems two things are
> >>>>> happening:
> >>>>>
> >>>>> 1. Messages were removed from output that shouldn't have. I do not
> >>>>> like that -m0 changed. What happened here? Either way it still printed
> >>>>> the #i76 lines which made this very confusing.  It also probably
> >>>>> breaks some host code of mine in Blue and other projects, but I really
> >>>>> don't have the time to investigate.
> >>>>> 2. Something changed with UDO calling. If I rollback to a commit a few
> >>>>> weeks ago the project runs fine, so this is a new problem.
> >>>>>
> >>>>> I did a git bisect session yesterday but it lead to commit that I do
> >>>>> not thing was the source of the problem:
> >>>>>
> >>>>> Your branch is up to date with 'origin/develop'.
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
> >>>>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
> >>>>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>>>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
> >>>>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
> >>>>> feature/webaudio-csound
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>>>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
> >>>>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
> >>>>> branch 'origin/develop' into feature/webaudio-csound-fs
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>>>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
> >>>>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
> >>>>> from gesellkammer/develop
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>>>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
> >>>>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
> >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7C761c10283a4848c14dea08d9d45bfec9%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637774314473042070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Dcc9kTeGJpXsSzZNoZ2zO%2FRWKiBjBMPAvi82RWQDMMg%3D&reserved=0 into develop
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>>>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
> >>>>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
> >>>>> sequ verbose case
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>>>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
> >>>>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>>>> Bisecting: 0 revisions left to test after this (roughly 1 step)
> >>>>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
> >>>>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> >>>>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
> >>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
> >>>>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
> >>>>>>
> >>>>>> Do you have a minimal test? I can't reproduce this here with a simple UDO like
> >>>>>>
> >>>>>> opcode Test,a,kk
> >>>>>> ka,kf xin
> >>>>>> asig oscili ka,kf
> >>>>>> xout asig
> >>>>>> endop
> >>>>>>
> >>>>>> instr 1
> >>>>>> a1 Test p4, p5
> >>>>>> out a1
> >>>>>> endin
> >>>>>>
> >>>>>> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
> >>>>>>
> >>>>>>
> >>>>>> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
> >>>>>>
> >>>>>> These are all names of UDOs; these print messages are breaking up
> >>>>>> audio and making live coding impossible. No idea yet where it's coming
> >>>>>> from.
> >>>>>>
> >>>>>> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
> >>>>>>
> >>>>>>
> >>>>>> No sign of these messaes in my tree as far as i can tell
> >>>>>>
> >>>>>> Are the sbus_mix strings in your code? Dittp in_scale/
> >>>>>>
> >>>>>>
> >>>>>> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
> >>>>>>
> >>>>>> I have not come across it, but I'll have a look
> >>>>>> tomorroe.
> >>>>>>
> >>>>>> Prof. Victor Lazzarini
> >>>>>> Maynooth University
> >>>>>> Ireland
> >>>>>>
> >>>>>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
> >>>>>>
> >>>>>> *Warning*
> >>>>>>
> >>>>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> >>>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I'm using the latest from the develop branch and there's some debug
> >>>>>> printing going on regarding UDO calls that happens even when -m0 is
> >>>>>> on. Does this ring a bell to anyone? I'm having difficulty finding the
> >>>>>> source of this (assume to be a printf somewhere).
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Steven
> >>>>>>
> >>>>>> p.s. messages look like this:
> >>>>>>
> >>>>>> #i76    in_scale        -2      0       0
> >>>>>>     sbus_mix        0       al      ar      0
> >>>>>>     sbus_mix        0       al      ar      0
> >>>>>>     sbus_mix        0       al      ar      0
> >>>>>>     sbus_mix        0       al      ar      0
> >>>>>>     sbus_mix        0       al      ar      0
> >>>>>>     sbus_mix        0       al      ar      0
> >>>>>>     sbus_mix        0       al      ar      0
> >>>>>> #i76    in_scale        -2      0       0
> >>>>>> #i76    in_scale        -2      0       0
> >>>>>> #i76    in_scale        -2      0       0
> >>>>>> #i76    in_scale        -2      0       0
> >>>>>>
> >>>>>> Seems to happen when the UDOs are called
> >>>>>>
> >>>>>>

Well then it was all wrong against what the manual said. The raw amplitudes are the amplitudes at the end of each section. I think that was there alright. 

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 10 Jan 2022, at 18:07, Steven Yi  wrote:
> 
> With -m0 I used to get error messages but not now. It did not show
> raw-amplitudes.
> 
>> On Mon, Jan 10, 2022 at 12:36 PM Victor Lazzarini
>>  wrote:
>> 
>> So the difference is that with -m0 we don't display the raw amplitudes. We could bring that back, but I fail to see it is much use.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>>> On 10 Jan 2022, at 17:10, Steven Yi  wrote:
>>> 
>>> But again this has broken backwards compatibility. I don't see how to
>>> get the messages that I used to get that were relevant to me and that
>>> I relied upon (having just errors and user-defined print statements).
>>> I absolutely can not use this for live coding if the above is not
>>> supported. BTW the latest manual still has:
>>> 
>>> 
>>> -m NUM, --messagelevel=NUM
>>> 
>>> Message level for standard (terminal) output. Takes the sum of any of
>>> the following values:
>>> 
>>> 1 = note amplitude messages
>>> 
>>> 2 = samples out of range message
>>> 
>>> 4 = warning messages
>>> 
>>> 128 = print benchmark information
>>> 
>>> 1024 = suppress deprecated messages
>>> 
>>> And exactly one of these to select note amplitude format:
>>> 
>>> 0 = raw amplitudes, no colours
>>> 
>>> 32 = dB, no colors
>>> 
>>> 64 = dB, out of range highlighted with red
>>> 
>>> 96 = dB, all colors
>>> 
>>> 256 = raw, out of range highlighted with red
>>> 
>>> 512 = raw, all colours
>>> 
>>> The default is 135 (128+4+2+1), which means all messages, raw
>>> amplitude values, and printing elapsed time at the end of performance.
>>> The coloring of raw amplitudes was introduced in version 5.04.
>>> Suppression of deprecated messages new in 6.14.
>>> 
>>>> On Mon, Jan 10, 2022 at 11:16 AM Victor Lazzarini
>>>>  wrote:
>>>> 
>>>> I don't know what these init errors are, I don't think I made any changes to that part of the code recently.
>>>> 
>>>> The fact that that line is still printed shows that I did not complete the reorganisation of logging, something is still in the confused state as before.
>>>> 
>>>> As far as I can recall, with my changes, it should be very easy to vary the logging level in terms of what should be printed. Rolling back to the chaotic state it was before it is not an option.
>>>> 
>>>> I still think that 0 should suppress all messages. We should make better use of the message level control instead of introducing more flags.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>>>> On 10 Jan 2022, at 16:09, Steven Yi  wrote:
>>>>> 
>>>>> I'm fine with having an ability to shut down all messages, but not if
>>>>> it breaks backwards compatibility. Let's find a different flag to use
>>>>> (and also find out why that one line was still being printed).
>>>>> 
>>>>> Anyone have leads on the new init-errors? Related to schedule maybe?
>>>>> Or some change in runtime code evaluation?
>>>>> 
>>>>>> On Mon, Jan 10, 2022 at 11:05 AM Victor Lazzarini
>>>>>>  wrote:
>>>>>> 
>>>>>> The change was discussed here. I had requests for this and I explained what I did.
>>>>>> 
>>>>>> I did quite a bit of work on this earlier on, because to be honest it was a real mess. At least things are more regular now.
>>>>>> 
>>>>>> We can discuss the level of messaging on Thursday too. I have no fixed idea but I quite like the ability to shut down all messages that we have now.
>>>>>> 
>>>>>> Prof. Victor Lazzarini
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>> On 10 Jan 2022, at 15:38, Rory Walsh  wrote:
>>>>>> 
>>>>>> 
>>>>>> Yes, -m0 definitely changed behaviour. This kind of blindsided me too. I had to update the template .csd files in Cabbage because of it.
>>>>>> 
>>>>>>> On Mon, 10 Jan 2022 at 16:21, Steven Yi  wrote:
>>>>>>> 
>>>>>>> I tried to make a minimal test but it also passed. I realized that -m0
>>>>>>> changed behavior and errors did not show up in the log. When I turned
>>>>>>> that off I got all the messages I didn't want plus the actual error
>>>>>>> messages I did want:
>>>>>>> 
>>>>>>> PERF ERROR in instr 2 (opcode in_scale) line 89: in_scale: not initialised
>>>>>>> #i76    in_scale    -2    0    0
>>>>>>> note aborted
>>>>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>>>>>> initialised
>>>>>>> from file livecode.orc (2), from file
>>>>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>>>>>> 0    al    ar    0
>>>>>>> note aborted
>>>>>>> PERF ERROR in instr 59 (opcode pan_verb_mix) line 1213: sbus_mix: not
>>>>>>> initialised
>>>>>>> from file livecode.orc (2), from file
>>>>>>> /Users/stevenyi/work/csound/live-code/livecode.csd (1),    sbus_mix
>>>>>>> 0    al    ar    0
>>>>>>> note aborted
>>>>>>> 
>>>>>>> This code runs fine and has run fine for ages. It seems two things are
>>>>>>> happening:
>>>>>>> 
>>>>>>> 1. Messages were removed from output that shouldn't have. I do not
>>>>>>> like that -m0 changed. What happened here? Either way it still printed
>>>>>>> the #i76 lines which made this very confusing.  It also probably
>>>>>>> breaks some host code of mine in Blue and other projects, but I really
>>>>>>> don't have the time to investigate.
>>>>>>> 2. Something changed with UDO calling. If I rollback to a commit a few
>>>>>>> weeks ago the project runs fine, so this is a new problem.
>>>>>>> 
>>>>>>> I did a git bisect session yesterday but it lead to commit that I do
>>>>>>> not thing was the source of the problem:
>>>>>>> 
>>>>>>> Your branch is up to date with 'origin/develop'.
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect start
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good 289c203bb
>>>>>>> Bisecting: 179 revisions left to test after this (roughly 8 steps)
>>>>>>> [aaca806423c03da316c796ed73aeab6f46e12c06] fixing test symlinks
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>>>> Bisecting: 89 revisions left to test after this (roughly 7 steps)
>>>>>>> [3ef3a2e5ec0674955a0aa7f1d18afd925d7273c7] Merge branch 'develop' into
>>>>>>> feature/webaudio-csound
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>>>> Bisecting: 42 revisions left to test after this (roughly 6 steps)
>>>>>>> [2bc0433dae72ba6e269e5f8a73608880477d5084] Merge remote-tracking
>>>>>>> branch 'origin/develop' into feature/webaudio-csound-fs
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>>>> Bisecting: 23 revisions left to test after this (roughly 5 steps)
>>>>>>> [f6333c49fba9edb44ecebe7774b3deaf0e8e48c0] Merge pull request #1554
>>>>>>> from gesellkammer/develop
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>>>> Bisecting: 10 revisions left to test after this (roughly 4 steps)
>>>>>>> [6fee202d3669e0d60436ce0a104f2df9e49298ae] Merge branch 'develop' of
>>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound&data=04%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9ac5876b04d4edec34908d9d463cce0%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C637774348334329564%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uUzDO9FcNmp1tjjDCItWrvdSJ6iUQgLDDzLdLFOVye4%3D&reserved=0 into develop
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>>>> Bisecting: 5 revisions left to test after this (roughly 3 steps)
>>>>>>> [bc3e0b1ce808b73efe98190c3088ec49d80b3189] small changes to metro and
>>>>>>> sequ verbose case
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>>>> Bisecting: 2 revisions left to test after this (roughly 2 steps)
>>>>>>> [d6658c1b9726af5f9582518f3aa85535498bfd80] investigating while in instr0
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>>>> Bisecting: 0 revisions left to test after this (roughly 1 step)
>>>>>>> [2e324328d0bf8b446b6c20082224de311982c4bb] trailing spaces
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect bad
>>>>>>> Bisecting: 0 revisions left to test after this (roughly 0 steps)
>>>>>>> [7417687bbf64bbca1ffcbd96601d6610bfe1d309] typo in sequ OENTRY
>>>>>>> (base) stevenyi@stevens-MacBook-Pro csound % git bisect good
>>>>>>> 2e324328d0bf8b446b6c20082224de311982c4bb is the first bad commit
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Mon, Jan 10, 2022 at 3:43 AM Victor Lazzarini  wrote:
>>>>>>>> 
>>>>>>>> Do you have a minimal test? I can't reproduce this here with a simple UDO like
>>>>>>>> 
>>>>>>>> opcode Test,a,kk
>>>>>>>> ka,kf xin
>>>>>>>> asig oscili ka,kf
>>>>>>>> xout asig
>>>>>>>> endop
>>>>>>>> 
>>>>>>>> instr 1
>>>>>>>> a1 Test p4, p5
>>>>>>>> out a1
>>>>>>>> endin
>>>>>>>> 
>>>>>>>> Also see if it is in the stderr or stdout. Maybe the parser is inserting these?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 10 Jan 2022, at 00:06, Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> These are all names of UDOs; these print messages are breaking up
>>>>>>>> audio and making live coding impossible. No idea yet where it's coming
>>>>>>>> from.
>>>>>>>> 
>>>>>>>> On Sun, Jan 9, 2022 at 6:33 PM john  wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> No sign of these messaes in my tree as far as i can tell
>>>>>>>> 
>>>>>>>> Are the sbus_mix strings in your code? Dittp in_scale/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Sun, 9 Jan 2022, Victor Lazzarini wrote:
>>>>>>>> 
>>>>>>>> I have not come across it, but I'll have a look
>>>>>>>> tomorroe.
>>>>>>>> 
>>>>>>>> Prof. Victor Lazzarini
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>> 
>>>>>>>> On 9 Jan 2022, at 21:10, Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> *Warning*
>>>>>>>> 
>>>>>>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> I'm using the latest from the develop branch and there's some debug
>>>>>>>> printing going on regarding UDO calls that happens even when -m0 is
>>>>>>>> on. Does this ring a bell to anyone? I'm having difficulty finding the
>>>>>>>> source of this (assume to be a printf somewhere).
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Steven
>>>>>>>> 
>>>>>>>> p.s. messages look like this:
>>>>>>>> 
>>>>>>>> #i76    in_scale        -2      0       0
>>>>>>>>    sbus_mix        0       al      ar      0
>>>>>>>>    sbus_mix        0       al      ar      0
>>>>>>>>    sbus_mix        0       al      ar      0
>>>>>>>>    sbus_mix        0       al      ar      0
>>>>>>>>    sbus_mix        0       al      ar      0
>>>>>>>>    sbus_mix        0       al      ar      0
>>>>>>>>    sbus_mix        0       al      ar      0
>>>>>>>> #i76    in_scale        -2      0       0
>>>>>>>> #i76    in_scale        -2      0       0
>>>>>>>> #i76    in_scale        -2      0       0
>>>>>>>> #i76    in_scale        -2      0       0
>>>>>>>> 
>>>>>>>> Seems to happen when the UDOs are called
>>>>>>>> 
>>>>>>>