"dates" example assumes working directory will be the same as csd file location

[tgrey1]

This printed line makes an incorrect assumption:

printf_i "File '%s' written to the same directory as this CSD file is!\n", 1, Sfilnam

The file will actually be written to whatever the working directory was when csound was executed. For example, running the example csd from up a directory: csound examples/dates.csd will demonstrate the issue.

This can be fixed by either changing the wording in the printed message, or by using an approach like the new pwd combination example suggested here: https://github.com/csound/manual/issues/318#issuecomment-711845782

[joachimheintz]

correct. just to note that the assumption was due to what csoundqt does (indeed here is the working directory the directory of the current csd). but for sure this manual should reflect the general csound case, so in doubt commandline usage. so i agree with your suggestion.

On 19/10/2020 10:43, tgrey1 wrote:

This printed line makes an incorrect assumption:

|printf_i "File '%s' written to the same directory as this CSD file is!\n", 1, Sfilnam|

The file will actually be written to whatever the working directory was when csound was executed. For example, running the example csd from up a directory: |csound examples/dates.csd| will demonstrate the issue.

This can be fixed by either changing the wording in the printed message, or by using an approach like the new pwd combination example suggested here:

318 (comment)

https://github.com/csound/manual/issues/318#issuecomment-711845782

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/csound/manual/issues/469, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQYHKUGAUQE3F2SLIRZV3LSLP32JANCNFSM4SV2RHPQ.

[csounder]

You could also suggest, in some cases, "run in terminal recommended" - possibly for some of the FLTK examples too.

Dr. Richard Boulanger

Professor of Electronic Production and Design

Berklee College of Music

Professional Writing and Technology Division

skype: radiobaton

facebook: https://www.facebook.com/richard.boulanger.58

about: http://www.boulangerlabs.com/#about

about: http://www.csounds.com/community/developers/dr-richard-boulanger/

music: http://www.csounds.com/community/developers/dr-richard-boulanger/dr-richard-boulanger-music/

Boulanger Labs - http://boulangerlabs.com

The Csound Book - http://mitpress.mit.edu/books/csound-book

The Audio Programming Book - http://mitpress.mit.edu/books/audio-programming-book

On Mon, Oct 19, 2020 at 12:16 PM joachimheintz notifications@github.com wrote:

correct. just to note that the assumption was due to what csoundqt does (indeed here is the working directory the directory of the current csd). but for sure this manual should reflect the general csound case, so in doubt commandline usage. so i agree with your suggestion.

On 19/10/2020 10:43, tgrey1 wrote:

This printed line makes an incorrect assumption:

|printf_i "File '%s' written to the same directory as this CSD file is!\n", 1, Sfilnam|

The file will actually be written to whatever the working directory was when csound was executed. For example, running the example csd from up a directory: |csound examples/dates.csd| will demonstrate the issue.

This can be fixed by either changing the wording in the printed message, or by using an approach like the new pwd combination example suggested here:

318 (comment)

https://github.com/csound/manual/issues/318#issuecomment-711845782

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/csound/manual/issues/469, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAQYHKUGAUQE3F2SLIRZV3LSLP32JANCNFSM4SV2RHPQ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://us-west-2.protection.sophos.com?d=github.com&u=aHR0cHM6Ly9naXRodWIuY29tL2Nzb3VuZC9tYW51YWwvaXNzdWVzLzQ2OSNpc3N1ZWNvbW1lbnQtNzEyMjc1ODM3&e=cmJvdWxhbmdlckBiZXJrbGVlLmVkdQ==&t=c1BpUERLWUo4SjdEa2Y1Y3JteG1heG0relBwaGhubDJOSGtDZ0lSckVCMD0=&h=f3f17a7fb99b49688380a8f5b79ed58b, or unsubscribe https://us-west-2.protection.sophos.com?d=github.com&u=aHR0cHM6Ly9naXRodWIuY29tL25vdGlmaWNhdGlvbnMvdW5zdWJzY3JpYmUtYXV0aC9BQUxXWUZVWjdCUFA0TEpFSjZCUTdFM1NMUlE1N0FOQ05GU000U1YyUkhQUQ==&e=cmJvdWxhbmdlckBiZXJrbGVlLmVkdQ==&t=OFhQK3ZjTDFCdmQ2VlhBTnpGd1pRSU1wR28vajVONzJaSHUzeG5rdjhNST0=&h=f3f17a7fb99b49688380a8f5b79ed58b .

[tgrey1]

@csounder I don't know, but my opinion is that if we're working to keep the csound manual front end agnostic I'd argue that we shouldn't be documenting these types of irregular behaviors here. It feels like something that should be covered in QT docs or elsewhere? Maybe a specific section about using csound with front ends?

Otherwise we will potentially need these types of caveats on a large number of manual pages for unknown numbers of front ends in the future.

FLTK should be a non-issue tho, since we'll be paring those down to only appear in FLTK opcode examples soon. ;)