This question is partially about CsoundQt and partially about using Python in Csound at all, so I’ll post it here.
The documentation on using Python in CsoundQt seems to be about ten years old, as it refers in passing to QuteCsound. It also displays a Mac screenshot. I’m using Windows 10. The Interactive CodePad has a Python mode, but it doesn’t correspond to what the documentation refers to, so that may or may not be a problem. Do I need to install a different version of CsoundQt?
I have Python 2.7 installed, and I’ve installed Csound with the Python checkbox in the installer checked. Nonetheless, the pyinit opcode causes a compiler error when I run a .csd in CsoundQt. Clearly something is not happening, and I don’t know what it is. Suggestions would be welcome!
This is all preliminary, as I’m not ready to start tinkering with Python yet, but it’s a little more than an Idle question, as I have a few ideas I’m hoping to explore.
No, they’re not listed in response to the -z command. And I did reinstall Csound this morning to make sure they were in the installation. This is very odd. I’ll try doing a computer restart, then reinstall Csound again and see what results I get.
I restarted the PC and tried the -z option from the Command Prompt. All of the opcodes are listed (as far as I can see – I didn’t count them!) but there were no Python opcodes. So I ran the Csound installer yet again (that would be Csound6_x64-windows_x86_64-6.18.0-1245.exe), making sure the Python checkbox was checked. And still, -z doesn’t list any Python opcodes.
And yes, I do have Python 2.7 installed.
This is starting to look like an oddball error in the installer. What would you suggest as my next steps?
I don’t think that the python opcodes are included in the installer anymore. The checkbox might be a remnant of the previous policy of including everything with the main distribution. There are at the moment no window binaries for those external plugins and no build instructions for windows. The python opcodes are being built for linux and macos using github actions (see Releases · csound-plugins/csound-externals · GitHub). The python version used for the build needs to match the installed version in your system. Python 2 is not supported.
Dang! Just last night I sent a feature article about Csound to the Synth & Software website, and in the article I touted the long-established policy that Csound is backward-compatible. But now it appears I lied. Csound is NOT backward-compatible. Older projects that Windows users might have written using the Python opcodes are now broken.
This is very, very not good. I am grievously disappointed.
No, Csound still does support python opcodes. As it appears, they are just not present in the Windows installer.
Strange that nobody noticed it before.
I am not sure who takes care of that and if it peopblematic to build and include the python opcodes.
Tarmo
R, 19. jaanuar 2024 19:00 JimAikin via The Csound Community <noreply@forum.csound.com> kirjutas:
Eduardo seems to suggest that there are no build instructions for those binaries, so even if I were able to compile Csound myself (and I’m not capable of doing that), I wouldn’t be able to use the Python opcodes.
It would be nice if this mess were straightened out. As it stands, older .csd files that used the Python opcodes are now broken – and that is never supposed to happen with Csound. Older files are always supposed to still be playable.
If Python 3 is required, that’s a different thing. I don’t mind updating my Python installation – but even if I do that, it won’t cause the Python opcodes to be installed by the installer.
Dang! Just last night I sent a feature article about Csound to the Synth & Software website, and in the article I touted the long-established policy that Csound is backward-compatible. But now it appears I lied. Csound is NOT backward-compatible. Older projects that Windows users might have written using the Python opcodes are now broken.
This is very, very not good. I am grievously disappointed.
I would, for starters, try to use a different language and have a different attitude if you want any kind of help.
Some plugins, which were previously distributed with the csound core as a convenience for users, were removed from the main distribution precisely to prevent this kind of problems. Those plugins are deeply dependent on other code with a complex tree of dependencies and the dev team decided (and noticed the community) to move those plugins to an external repository. The core of csound remains compatible and great efforts are taken to make sure that that remains so while still allowing evolution.
Was I wrong to be disappointed? Should I have hidden my disappointment rather than expressing it? I hope you’ll clarify what you meant by this.
I’m confused. You seem to be saying that causing a problem is a way of preventing a problem. The problem I mentioned, which is quite real, is that some Csound files that formerly worked no longer work with 6.18.
I understand that the Python opcodes are dependent upon Python. And it’s quite possible that the dependencies run deeper than the fact that Python 3.x is now standard while 2.7 is deprecated. Nonetheless, if a user still has Python 2.7 installed, it’s reasonable to imagine that the py- opcodes in their original form would still work.
Perhaps these opcodes should never have been included in Csound in the first place, since their continued validity could not be guaranteed due to external dependencies.
This observation raises, in turn, a question that might be worth investigating: Are there any other opcodes in the current distribution that rely on external dependencies and that, for that reason, ought never to have been included?
I understand that most of the Csound community consists of people who routinely run compilers and can figure out how to fix this sort of problem if they need to. But not all of us are in that category. I’m just a musician. When something breaks, I can’t fix it. My external dependency is, I suppose we would have to say, the entirety of the Csound developer community.
I think Eduardo explained well the reason behind leaving several plugins out.
In the same time, Jim, Your view is welcome and brings out what can be problems for a newcomer or a person who has been away from the community
for some time, what information is hard to find and what is missing. Any feedback is always in place.
But as they say - finding volunteers to write documentation is even harder than finding developers.
Are you willing to help?
Perhaps to write a wiki page about your experiences and hints on getting started on Windows? https://github.com/csound/csound/wiki
I believe the article you mentioned is a great resource already, is it out somewhere already?
And please issue tickets on the bug tracker https://github.com/csound/csound/issues (like “Python checkbox in the Windows installer has no effect”)
What concerns the extra plugins and windows - I am sure it is possible to build them and prepare for the package but there is noone who would volunteer doing it. I completely agree, it should bot be a burden for the main developers. If you know someone, I am sure the developers would help with giving hints how to do it and prepare for the next Windows package.
If you need python opcodes in your work, then I think the best bet on Windows at the moment is to go back to Csound 6.16, all Csound releases are up here: https://github.com/csound/csound/releases/
I believe, CsoundQT 1.1.x should work with it as well. Please let know, if you decide to try it out and what is the result.
Thanks!
Tarmo
Seems that
Kontakt JimAikin via The Csound Community (<noreply@forum.csound.com>) kirjutas kuupäeval R, 19. jaanuar 2024 kell 21:50: