Nice. How did you put it all together?

On 23 December 2011 20:03, Anton Kholomiov  wrote:
> ooups, here it is
>
> http://soundcloud.com/anton-kho/lighthouse
>
>
> 2011/12/24 Anton Kholomiov 
>>
>> Here is my first csound composition. Night, sea and blinking stars
>>
>> Anton
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

http://soundcloud.com/anton-kho/lighthouse

2011/12/24 Anton Kholomiov <anton.kholomiov@gmail.com>

... my first csound composition. Night, sea and blinking stars

Anton Kholomiov wrote:

> Main strength is composability of score parts. In *.hs file score part
> takes 50 lines
> and in *.csd it is almost 700. There are loops that can be hided with
> special
> csound-structures. But in *.hs-code this special structures are just
> ordinary
> functions that can be used in another functions.

As a Haskell guy, I find the Haskell code far more readable than
a Csound score or orchestra :-).

In an earlier email you said:

> I haven't done much more because there are some implementation problems
> that I can not resolve. Library works really slow on big instruments
> (>1000 lines of csound code).

What ere these problems? 

Cheers,
Erik

<>

Yes, but - 

1) The cave was "turned on" at some time in the distant past, and may be
"turned off" by seismic or other activity in the future. Triggering it for
the duration of the score is the closest csound can come to modeling this.

2) With "alwayson", the cave can be defined as a pre-existing "given" within
the orchestra, and need not be triggered from the score.

3) Having the option of triggering the cave from the score makes it possible
to change the shape or size of the cave over the course of the performance.

Something I think would go a long way toward increasing the possibilities
would be unrestricted use of strings in p-fields, so that an instrument
could be told to direct its output (or receive its input) from a particular
named channel. Some instruments (or some of a given instrument's notes)
could then be sent to the cave, others to the spring, and still others could
be transformed first by one and then the other.

My sense is that right now, the haskell functions can pass instruments and
score events around as first class entities, but not signal routes, and that
allowing an instrument to pass both a signal [via a named channel] and the
name of the channel to which the second instrument should direct its signal
output, would enable such manipulation. Think of Anton's earlier example,
where each score invocation of Instrument B triggers a series of Instrument
A notes, whose signal outputs are then returned to that particular instance
of B, for further processing controlled by other per-score-note parameters
included in the score invocation of B. If each B instance could pass a
unique channel name to its sequence of "A"s, and listen on that channel, the
problems he encountered in his initial attempts are gone.

It would also be helpful if an instrument could access its internal instance
number; that is, if 5 "B" instruments have been physically allocated, and
the 14th Instrument B "note" knew which of those 5 it was using, it could
append that instance number to a prefix defined within the instrument or
passed from the score, and construct a guaranteed unique channel name to
communicate with its "A"s. Would this be possible?

- Henry L.

--------------------------------------------------------------------------------------

Dec 24, 2011; 2:37pm — Anton Kholomiov

Here goes some heresy from csound point of view.
But my intuition tells me that score-orchestra subdivision
is artificial. It does exist, but score level doesn't sit
on top of instrument-level. Scores played with instruments
becomes a signal. Which can be transformed somehow.

Simple example about echo. Imagine string quartet that plays
Bach in the cave. Every musician plays notes and produces
signal. The signal hits the walls, walls are producing echo.
Here cave is a transformation. It's not an instrument to
be triggered (and held until musicians decide to end the show).

I tried to implement this model with haskell. I need
a way to render to csound a function:

sco :: Score Signal -> Signal

----------------------------------------------------
-- WARNING. some haskell-spoiler ahead
-----------------------------------------------------

Here Score - is some container of events. Event
contains start time, duration, and Signal. I have no
clue how to manage it. My brain is drowned in
possible combinations (as you can see that result
of sco function can become the argument of sco function,
aaah, and i have to reduce it to score-orchestra).

My library can not do it at all. You will find some ugly
(in functional programming setting) functions that try to imitate csound
globals. There are some good things it can do.
It can convert container (Score Signal) to csd-file.
There is no notion of instrument. csound-instruments are
derived from (Score Signal) value. But! this procedure
requires to extract function from pool of values.
My algorithm is not an ideal one, but in any algorithm
speed of rendering depends on size of the signal
description and length of the (Score) container.
A lot of notes and big instruments make it impractical
to use. I've tried to implement woodwind from csound book.

Having no instruments allows composer to choose
any representation for note, provided you
can build signals from notes.

Anton

--
View this message in context: http://csound.1045644.n5.nabble.com/new-composition-lighthouse-tp5097968p5103749.html
Sent from the Csound - General mailing list archive at Nabble.com.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"