I may live to regret this message.....

I am contemplating the next release of Csound.  Already there are a
number of changes, fixes and new stuff.  Cruising back through my
retained e-mail today I found a bug report about macros in comments that
I have forgotten or not read -- fixed now on this machine -- but it
got me thinking about what else had slipped down the cracks.

so......

1:  Please can you report all outstanding bugs that you think remain
from the last release.  Either to the list or to me and I will
collate.

2:  With even less promises, are there facilities that you REALLY
would like the developers to deliver?  Either in the next release or
soon.

==John ffitch

--- jpff  wrote:
> 1:  Please can you report all outstanding bugs...

* 'adsyn' and friends are non-functional.

* Python extension modules are built, but not installed (except
by hand)

* STK opcodes compile from source, but Loris fail (they seem to
want a file that doesn't exist).

> Are there facilities that you
> REALLY
> would like the developers to deliver?

* Unless I'm missing it . . . documentation for CsoundAC?

* And a hard boiled egg. [Sorry, that was from the Marx
Brothers.]

--BMC

> 2:  With even less promises, are there facilities that you REALLY
> would like the developers to deliver?  Either in the next release or
> soon.

windows binaries distributed as a plain zip, without installer, and 
without python dependency.

that would be nice :)


Stef

You took the words right out of my mouth.

Loris on windows would be great.

a complete "resynthesis audit" is probably a good idea in some form or other
at some stage (i have variously seen problems or issues reported with LPC,
Loris, & Hetro / sdif - I have also encountered problems with ATS noise, but
not had time to return to the issue with any thoroughness, & jpff failed to
reproduce my errors, so cross that out for the mo...)

a ktimpt playback method for a wider variety of SDIF files (incl bit depths
>16 etc) would be awesome (although i guess the whole nature of the
non-frame based types of SDIF analysis is counter-productive to ktimpt style
playback - & what i have seen of frame based SDIF methods via SPEAR (whose
expiry date is rapidly approaching, i get no answers from the author,
anybody else?) is that they dont preserve "partial continuity" from frame to
frame, in terms of the frequency continuing to match / align with the "bin"
identity, which does seem decidely "un-partial" like. (i have devised my own
adsynt based "pre-interpolated frame method" for handling small amounts of
SDIF data as a workaround, based on SPEAR created .txt files of SDIF
data...)

Id also like to see direct opcode implementations of some of the constituent
processes at the heart of the resynthesis methods - a "bandwith enhanced
partial opcode" that provides simple parametric input to emulate bandwith
enhanced partial synthesis directly. one that uses an LPC type algorithm,
one a loris type algorithm, one an ATS type algorithm - a "bark scale based"
multi band noise generator perhaps? This would allow more flexibility &
customisation of hybrid synthesis / resynthesis methods (particularly if all
the resynth methods were capable of producing "reports" on their analysis
data suitable for manipulation in Python or simlar.. &/or supplying data in
a "transparent" or "interceptable & alterable" way to these opcodes.

residual analysis & output from pvs tracks (with direct data manipulation
possible?)

i have had some problems with adsynt2 (the interpolating one). it's not
essential to me, i've never reported it. I will make a point of trying to
post a bug report on this over the next week or so.

Multiple MIDI out ports - somehow?

The capacity to send score statements as string variables directly out from
pyops?

API tutorial documentation suitable for idiots like me who only can use the
Python API, & that gives some sort of overview of compatible groupings of
functions to achieve key implementation scenarios.

makes me sound ungreatful doesn't it. Im not. csound is the bomb. i thank my
lucky stars every day that i am alive & that csound & this community exists
& that i speak english thus enabling my full & fanatical participation! 

If i die tomorrow put Oeyvinds bug fix of my real time MIDI API model on my
tombstone.

Lest we forget.


Bruce H. McCosar wrote:
> 
> --- jpff  wrote:
>> 1:  Please can you report all outstanding bugs...
> 
> * 'adsyn' and friends are non-functional.
> 
> * Python extension modules are built, but not installed (except
> by hand)
> 
> * STK opcodes compile from source, but Loris fail (they seem to
> want a file that doesn't exist).
> 
>> Are there facilities that you
>> REALLY
>> would like the developers to deliver?
> 
> * Unless I'm missing it . . . documentation for CsoundAC?
> 
> * And a hard boiled egg. [Sorry, that was from the Marx
> Brothers.]
> 
> --BMC
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 


-----
*******************
www.phasetransitions.net
hermetic music * python * csound * possibly mindless ranting
various werk in perpetual delusions of progress....

-- 
View this message in context: http://www.nabble.com/Tentative-request-tp17092598p17093471.html
Sent from the Csound - General mailing list archive at Nabble.com.

completely agree.

Victor's Macintosh Installers are fantastic.

It needs to be as easy again for the Windows *users* *owners*  
*students* too.

It used to be that easy - back in the day of Winsound.

-dB

On May 6, 2008, at 6:09 PM, Stéphane Rollandin wrote:

>
>> 2:  With even less promises, are there facilities that you REALLY
>> would like the developers to deliver?  Either in the next release or
>> soon.
>
> windows binaries distributed as a plain zip, without installer, and  
> without python dependency.
>
> that would be nice :)
>
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

El Tue,  6 May 2008 20:57:13 +0100
jpff  escribió:


> 2:  With even less promises, are there facilities that you REALLY
> would like the developers to deliver? 

this is indeed dangerous...

a modest proposition (i think):

it would be nice if we could control position and size of the fltk
window showing the output of dispfft. four extra arguments would do (x
- y of the upper left corner, x-size - y-size)

a not-so-modest proposition:

what i would *really* like is having FL-opcodes equivalent to dispfft
and display. that way we could control not only size and positions of
the displays, but we could also have fft *and* oscillogram at the same
time and integrate them on a panel with other FLTK widgets.

that's the only wish i can think of for now.

best,

lj

how about a build of the api on OSX which is python-version independent?
That'd mean I could make music again. :-)

David

On 07/05/2008, at 9:55 AM, luis jure wrote:

> El Tue,  6 May 2008 20:57:13 +0100
> jpff  escribió:
>
>
>> 2:  With even less promises, are there facilities that you REALLY
>> would like the developers to deliver?
>
> this is indeed dangerous...
>

jpff wrote:
> 
> I may live to regret this message.....
> 
> 2:  With even less promises, are there facilities that you REALLY
> would like the developers to deliver?  Either in the next release or
> soon.
> 
> 

I'd like to see implemented deferred tables for tablexkt opcode.
Thanks.

-- 
View this message in context: http://www.nabble.com/Tentative-request-tp17092598p17109631.html
Sent from the Csound - General mailing list archive at Nabble.com.

There are already multiple ways of achieving this, but I think a set of
conveniently named fundamental waveform oscillator types would be a big boon
to those new to Csound:

a1 sine xamp, xcps, [, xphs]
k1 sine kamp, kcps, [, kphs]

a1 triangle xamp, xcps, [, xphs]
k1 triangle kamp, kcps, [, kphs]

a1 saw xamp, xcps, [, xphs]
k1 saw kamp, kcps, [, kphs]

a1 square xamp, xcps, [, xpw] [, xphs] 
k1 square kamp, kcps, [, kpw] [, kphs] 

Each opcode would produce the truest shape possible instead of band-limited
waveforms produced by opcodes such as vco and vco2.  The optional parameters
would accept normalized values between 0 and 1.  Values outside of this
range for "phs" would wrap, so that a value of 1.2 would translate as a
value of 0.2.  In the case of "pw" in the square opcode, the range would be
strictly limited between 0 and 1, so that a value of 1.2 would translate to
a value of 1.0.  Values of either 0 or 1 in "pw" would produce no pulse,
just a bias. "phs" would have a default value of 0.  "pw" would have a
default value of 0.5.

My reasons? I believe these proposed opcodes would help beginners skip much
of the early confusion of dealing with tables and strange terms like
"band-limited."  These would also have the added bonus of reducing table
clutter, and in some cases, instruments that can seamlessly migrate between
orchestras without having to correct table numbers.

Just a suggestion.  And I won't be heartbroken if this isn't implemented. 
:)

Best,
Jake
---- 
The Csound Blog 
http://www.thumbuki.com/csound/blog/




jpff wrote:
> 
> 2:  With even less promises, are there facilities that you REALLY
> would like the developers to deliver?  Either in the next release or
> soon.
> 

-- 
View this message in context: http://www.nabble.com/Tentative-request-tp17092598p17109834.html
Sent from the Csound - General mailing list archive at Nabble.com.

Jacob Joaquin wrote:
> There are already multiple ways of achieving this, but I think a set of
> conveniently named fundamental waveform oscillator types would be a big boon
> to those new to Csound:
>
> a1 sine xamp, xcps, [, xphs]
> k1 sine kamp, kcps, [, kphs]
>   
yes, this would be great! everything that helps instruments be as much 
self-contained as possible.

best,
atir
> My reasons? I believe these proposed opcodes would help beginners skip much
> of the early confusion of dealing with tables and strange terms like
> "band-limited."  These would also have the added bonus of reducing table
> clutter, and in some cases, instruments that can seamlessly migrate between
> orchestras without having to correct table numbers.
>
> Just a suggestion.  And I won't be heartbroken if this isn't implemented. 
> :)
>
> Best,
> Jake
> ---- 
> The Csound Blog 
> http://www.thumbuki.com/csound/blog/
>
>
>
>
> jpff wrote:
>   
>> 2:  With even less promises, are there facilities that you REALLY
>> would like the developers to deliver?  Either in the next release or
>> soon.
>>
>>     
>
>   

A nice idea, but I think they should be bandlimited, because if they are 
not the sound quality is definitely lower, and that may disappoint 
beginners. I sure was glad to discover vco2. If these opcodes would not 
be bandlimited, I'm afraid they would soon be considered newbie opcodes.

Adding some short explanation about bandlimited should be fine.

As to reduce table clutter, I think manuals should not explain how to 
make tables with the f-statement, but use ftgen instead, like in

gi_sine ftgen 0, 0, 65536, 10, 1

which automatically assigns numbers (I've even seen ftgen inside 
instrument definitions, although the manual says not to; it would be 
nice if it were guaranteed to work). Initially the f-statement drove me 
crazy, and I was glad to later discover ftgen. ftgen can even be used 
for instruments that have a table number as a p-field, just replace the 
first 0 with the desired number (at least, I think you have to do it 
that way).

As a sidenote, replacing the gen number (the 10 in my example) by a name 
would be nice for readability. Or perhaps new opcodes that replace 
ftgen, like

gi_sine ftgensines 0, 0, 65536, 1


Mark


Jacob Joaquin schreef:
> There are already multiple ways of achieving this, but I think a set of
> conveniently named fundamental waveform oscillator types would be a big boon
> to those new to Csound:
>
> a1 sine xamp, xcps, [, xphs]
> k1 sine kamp, kcps, [, kphs]
>
> a1 triangle xamp, xcps, [, xphs]
> k1 triangle kamp, kcps, [, kphs]
>
> a1 saw xamp, xcps, [, xphs]
> k1 saw kamp, kcps, [, kphs]
>
> a1 square xamp, xcps, [, xpw] [, xphs] 
> k1 square kamp, kcps, [, kpw] [, kphs] 
>
> Each opcode would produce the truest shape possible instead of band-limited
> waveforms produced by opcodes such as vco and vco2.  The optional parameters
> would accept normalized values between 0 and 1.  Values outside of this
> range for "phs" would wrap, so that a value of 1.2 would translate as a
> value of 0.2.  In the case of "pw" in the square opcode, the range would be
> strictly limited between 0 and 1, so that a value of 1.2 would translate to
> a value of 1.0.  Values of either 0 or 1 in "pw" would produce no pulse,
> just a bias. "phs" would have a default value of 0.  "pw" would have a
> default value of 0.5.
>
> My reasons? I believe these proposed opcodes would help beginners skip much
> of the early confusion of dealing with tables and strange terms like
> "band-limited."  These would also have the added bonus of reducing table
> clutter, and in some cases, instruments that can seamlessly migrate between
> orchestras without having to correct table numbers.
>
> Just a suggestion.  And I won't be heartbroken if this isn't implemented. 
> :)
>
> Best,
> Jake
> ---- 
> The Csound Blog 
> http://www.thumbuki.com/csound/blog/
>
>
>
>
> jpff wrote:
>   
>> 2:  With even less promises, are there facilities that you REALLY
>> would like the developers to deliver?  Either in the next release or
>> soon.
>>
>>     
>
>   

-- 
  Mark
  _________________________________________
  When you get lemons, you make lemonade.
  When you get hardware, you make software.

I've been using adsyn extensively on a current project with no 
difficulty (WindowsXP, cs ver 5.07). Just have to remember not to 
multiply outs by 0dbfs.

At 05:31 PM 5/6/2008, you wrote:
>--- jpff  wrote:
> > 1:  Please can you report all outstanding bugs...
>
>* 'adsyn' and friends are non-functional.
>

David Mooney:  dmooney@city-net.com
Maxine Heller:  mheller@city-net.com
Opaque Melodies:  www.city-net.com/~moko/

Hi All

my msrOsc opcode in the UDO library is a first cut at that 
functionality. I don't know that it addresses every possible issue, but 
you get basic wave forms that don't click at start and stop.

Michael

Steven Yi wrote:
> I think this should definitely be done using a set of User-Defined Opcodes.
>
> On Wed, May 7, 2008 at 10:06 AM, Jacob Joaquin  wrote:
>   
>>  There are already multiple ways of achieving this, but I think a set of
>>  conveniently named fundamental waveform oscillator types would be a big boon
>>  to those new to Csound:
>>
>>  a1 sine xamp, xcps, [, xphs]
>>  k1 sine kamp, kcps, [, kphs]
>>
>>  a1 triangle xamp, xcps, [, xphs]
>>  k1 triangle kamp, kcps, [, kphs]
>>
>>  a1 saw xamp, xcps, [, xphs]
>>  k1 saw kamp, kcps, [, kphs]
>>
>>  a1 square xamp, xcps, [, xpw] [, xphs]
>>  k1 square kamp, kcps, [, kpw] [, kphs]
>>
>>  Each opcode would produce the truest shape possible instead of band-limited
>>  waveforms produced by opcodes such as vco and vco2.  The optional parameters
>>  would accept normalized values between 0 and 1.  Values outside of this
>>  range for "phs" would wrap, so that a value of 1.2 would translate as a
>>  value of 0.2.  In the case of "pw" in the square opcode, the range would be
>>  strictly limited between 0 and 1, so that a value of 1.2 would translate to
>>  a value of 1.0.  Values of either 0 or 1 in "pw" would produce no pulse,
>>  just a bias. "phs" would have a default value of 0.  "pw" would have a
>>  default value of 0.5.
>>
>>  My reasons? I believe these proposed opcodes would help beginners skip much
>>  of the early confusion of dealing with tables and strange terms like
>>  "band-limited."  These would also have the added bonus of reducing table
>>  clutter, and in some cases, instruments that can seamlessly migrate between
>>  orchestras without having to correct table numbers.
>>
>>  Just a suggestion.  And I won't be heartbroken if this isn't implemented.
>>  :)
>>
>>  Best,
>>  Jake
>>  ----
>>  The Csound Blog
>>  http://www.thumbuki.com/csound/blog/
>>
>>
>>
>>
>>
>>  jpff wrote:
>>  >
>>  > 2:  With even less promises, are there facilities that you REALLY
>>  > would like the developers to deliver?  Either in the next release or
>>  > soon.
>>  >
>>
>>  --
>>  View this message in context: http://www.nabble.com/Tentative-request-tp17092598p17109834.html
>>
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>>  To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>     
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
>
> E-mail message checked by Spyware Doctor (5.5.0.178)
> Database version: 5.09780
> http://www.pctools.com/spyware-doctor/
>
>