[Csnd] dmp.csound~ is now csound~ (fwd)
Davis Pyon has created a new version of csound~
that runs on mac and win:
As mentioned in the subject, dmp.csound~ is now simply csound~. Csound 5.01
is required now for 64bit csound~ on WinXP. All other versions do not have this
requirement. At the end of this email is a list of new features and changes.
Download it here:
Big thanks to Matt Ingalls for the name. Big BIG thanks to Matt and Victor
for their externals. Their source code served as my API documentation (csound.h
doesn’t really count).
-> If using 64bit csound~ on WinXP, Csound 5.01 (or later) is required.
-> Added the "noscale" flag. It’s used to bypass audio data scaling
-> Added another outlet that sends a bang whenever a csd/orc is
successfully compiled. It’s a useful feature if you have MIDI
control opcodes that need to be initialized from the Max environment.
-> Added messages "m", "c", and "e" which are equivalent to
"midi", "control", and "event", respectively. These new messages
are intended to save screen space.
-> If neither -d or -g is present in the "csound" message, then csound~
will add -g to allow the user to see the ASCII representation of
tables. Either -d or -g must be present to prevent crashing.
-> Added bang method which acts like the "start" message. Added
for compatibility with Ingalls’ csound~ patches.
The following changes were made in order to add features that were in
Matt Ingalls’ version of csound~.
-> Renamed dmp.csound~ to csound~.
-> Added second optional integer argument to specify # of output signals.
If no arguments are supplied, then there are 2 input/output signals.
If 1 argument is supplied, then that argument specifies the # of input/output
signals. If 2 arguments are supplied, the first is the # of input signals
and second is the # output signals.
-> After "start" message is received, if the # of Csound audio channels != the
# of input or output signals for the external, a warning is displayed.
-> Added "printout" message which works exactly like "message" message.
-> If csound~ has not received a "path" message to set the current directory,
relative pathnames in the "csound" will be relative to the directory
that contains the patch that contains csound~.
-> Added the "sfdir" message. The "sfdir" has one argument which should be the
pathname to a directory. That directory will be used to set the SFDIR, SSDIR,
SADIR, INCDIR, and CSSTRNGS global environment variables. By default, these
env variables are set to the defualt directory (see above). At the moment,
I don’t know what the INCDIR and CSSTRNGS variables are for, but they were set
in Ingalls’ csound~ so I set them just in case.
-> Changed behavior of "start" message. When "start" is passed to [dmp.csound~],
the current directory is reset to the directory that was given as part of the
last "path" message. If "path" has not been received yet, then nothing is done.
This should fix the problem where other instances of [dmp.csound~] have a
different directory saved as the current directory.
Send bugs reports to this list.
To unsubscribe, send email to firstname.lastname@example.org
thanks thanks thanks thanks thanks
thanksthanksthanksthanksthanksthanksthanksthanksthanksthanks thanksthanksthanksthanksthanksthanksthanksthanksthanksthanks thanksthanksthanksthanksthanksthanksthanksthanksthanksthanks thanksthanksthanksthanksthanksthanksthanksthanks
Definitely, this Csound~ chick has a tremendous chastity belt !
Have uninstalled the corrupted Csound5 package by Istvan Varga (looking
for python23 when you got 24, very interesting…), installed the new
one from sourceforge (Csound5.01b-win32), made the corrections for the
paths (quiet a few, indeed ! : lib or plugins instead of bin
everywhere…), grabbed the missing sound32.dll and the
portaudio.dll.0.0.19 from the .zip archive (the supposed 32bits version
doesn’t install the 32bits lib, could you believe it !!!), tested it
with python24 (ok, just some wxPython file missing) and… ERROR 126.
So, as we all know, 126 means "i can’t find a .dll", i assume it’s not
my Csound (’cause it’s working), but the bloody pthreadVC2.dll which
couldn’t be find (for no reason i could understand) or another lib, but
which one ???
If anyone here get success with her on windows, please, share it !!
I suggest downloading either:
Unarchive and replace the installation of Csound5.01b-win32.exe with the .zip
contents. Then put pthreadVC2.dll in C:WindowsSystem32 or C:Csoundbin (if
that’s where the csound32/64.dll’s are located). Assuming that your environment
variables were set properly by Csound5.01b-win32.exe, then everything should work.
I’m sorry for the instructions in INSTALL.TXT as Csound5 has been experiencing
problems with regards to packaging. When Csound5.01-win32.exe is released, it will
have everything needed to run either 32 or 64bit csound~. Let me know if you’re
still having problems.
I tried your new csound~, when it loads it gives me
an error "can not find csound32.dll". I currently have
Csound5.01b-win32.exe installed, it works fine, but
csound32.dll does not exist in my csound installation folder.
Interestingly though, dmp.csound~ do not have this problem. Is
there something I am missing?
Okay I found the install.txt file. That is a lot of
trouble, I guess I can use dmp.csound~ for now. When
will there be a new version of csound~ that matches
The new csound~ expects either csound32.dll or csound64.dll to
be in the bin folder of your Csound installation. I did things this
way because that’s how future releases of Csound will be configured.
To use the new csound~, I suggest downloading either:
Replace your existing Csound folder with the contents of the .zip file.
Do it in such a way that your environment variables PATH, OPCODEDIR, and
OPCODEDIR64 don’t have to be modified, and the new csound~ should work.
I’m going to modify INSTALL.TXT to prevent further confusion. Keep an
eye on Csound at Sourceforge. When the non-beta installer
Csound5.01-win32.exe is released, it will be compatible with csound~
(fingers crossed). I hope this clears things up.
Thanks, I will keep an eye out for it.