But then the channel lists would be duplicated on the host side
and Csound? This means that the same channel would be counted
on both lists? Istvan's system does not use callbacks, how would
we merge values set by Csound and set by the host via a callback?

Sounds complicated to me.

Victor

----- Original Message ----- 
From: "matt ingalls" 
To: "Developer discussions" 
Sent: Thursday, January 24, 2008 8:30 PM
Subject: Re: [Cs-dev] software busses


>i guess i wasn't clear.
>
> all i am suggesting is to ADD to invalue/outvalue a hook into Istvan's
> system.
> so invalue/outvalue would work the same but also allocate a (k or S)
> channel
> in the other system and set (and get?) the value in Istvan's system.
>
> invalue/outvalue would just be labeled as deprecated
> so that new hosts use Istvan's system.
>
> (maybe John's system could be treated the same too - or is already? -
> i haven't looked into it)
>
> On Jan 24, 2008, at 12:15 PM, victor wrote:
>
>> The problem is that csoundapi~ uses invalue/outvalue with
>> its callbacks and changing will probably mean that I would have
>> to change my code, which works...
>>
>> I guess csound~ also depends on it.
>>
>> Shall we leave it as is?
>>
>> Victor
>> ----- Original Message -----
>> From: "matt ingalls" 
>> To: "Developer discussions" 
>> Sent: Thursday, January 24, 2008 8:08 PM
>> Subject: Re: [Cs-dev] software busses
>>
>>
>>> what i just suggested would not break anything!
>>>
>>> On Jan 24, 2008, at 11:50 AM, victor wrote:
>>>
>>>> We cannot break backwards compatibility. I don't see
>>>> how this can be done without breaking anything. I would
>>>> leave as it is.
>>>> ----- Original Message -----
>>>> From: "Rory Walsh" 
>>>> To: "Developer discussions" 
>>>> Sent: Thursday, January 24, 2008 7:47 PM
>>>> Subject: Re: [Cs-dev] software busses
>>>>
>>>>
>>>>> It would be nice to agree some kind of standard as more people are
>>>>> using
>>>>> the API now then ever. Having the system compatible would be a step
>>>>> in
>>>>> the right direction IMO, what do others think?
>>>>>
>>>>>
>>>>> matt ingalls wrote:
>>>>>> well.. i hesitate to join in this discussion because i am still
>>>>>> bitter
>>>>>> about this... but since we are going of the history:
>>>>>>
>>>>>> i added invalue/outvalue around 2000 or something like that -  it
>>>>>> was in
>>>>>> my original API, even before i merged with Michael's.  It looks
>>>>>> like
>>>>>> those functions were finally rolled into canonical in 2002.
>>>>>> ( BTW
>>>>>> invalue/outvalue can use numbers OR strings for the channel
>>>>>> name. )
>>>>>>
>>>>>> It is a real shame that the invalue/outvalue system was just not
>>>>>> added
>>>>>> to (even after my multiple pleas and offer to add my host's code
>>>>>> to
>>>>>> handle the channel matrixing) and these 2 other "replacement"
>>>>>> systems
>>>>>> were added instead.  Istvan's system is almost identical to what i
>>>>>> do
>>>>>> with invalue/outvalue, except for the extra feature (confusion?)
>>>>>> of bus
>>>>>> direction and channel types.
>>>>>>
>>>>>> ===
>>>>>>
>>>>>> ANYWAY,  it  bugs me that there are multiple ways to do the same
>>>>>> thing
>>>>>> and was recently ready to suggest to retire invalue/outvalue and
>>>>>> only
>>>>>> support the other channel bus stuff.
>>>>>>  if CsoundChannelIOCallback_t does work, then we could probably
>>>>>> have
>>>>>> invalue/outvalue call that as well, which would then make
>>>>>> invalue/outvalue work with Istvan's chn system, and we could call
>>>>>> invalue/outvalue deprecated (but still be functional for the time
>>>>>> being).  Host developers would only need to support Istvan's
>>>>>> system,
>>>>>> although i think implementing a CsoundChannelIOCallback_t should
>>>>>> be
>>>>>> strongly advised so that orcs could call the same channel multiple
>>>>>> times
>>>>>> in one k-pass.
>>>>>>
>>>>>>
>>>>>> -m
>>>>>>
>>>>>>
>>>>>> On Jan 24, 2008, at 1:46 AM, jpff wrote:
>>>>>>
>>>>>>> The software bus was originally conceived by Richard Dobson way
>>>>>>> back
>>>>>>> before the software freeze.  As no one actually submitted code I
>>>>>>> wrote
>>>>>>> the numbered bus commands in September 2004 as part of Csound5.
>>>>>>> Over a
>>>>>>> year later another developer wrote the named versions without
>>>>>>> discussions.  Personally I like numbers as they are easier to
>>>>>>> manipulate, but whatever.
>>>>>>> ==John ffitch
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>> matt ingalls
>>>>>> development@gvox.com 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by: Microsoft
>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> matt ingalls
>>> development@gvox.com
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> matt ingalls
> development@gvox.com
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

matt ingalls wrote:
> 
> On Jan 24, 2008, at 12:42 PM, victor wrote:
> 
>> But then the channel lists would be duplicated on the host side
>> and Csound? 
> 
> yes, but only for compatibility.  any new host could just use 
> csound's list.  the header file states that Csound's list of 
> string and audio values do not become accessible until the render
> begins.  audio makes sense, but i would like to change that
> so string values could exist outside the render too.
> 
>> This means that the same channel would be counted
>> on both lists? Istvan's system does not use callbacks, how would
> 
> but what about:
> 
>   PUBLIC void csoundSetChannelIOCallback(CSOUND *,
>                                          CsoundChannelIOCallback_t func);
> 
> ?? it looks like this is identical to 
> csoundSetInputValueCallback/csoundSetOutputValueCallback?
> 
>>
>> we merge values set by Csound and set by the host via a callback?
> 
> 
> well i am just proposing a way to ensure backwards compatibility.  i
> would assume
> most orcs would just use one family of opcodes and the only conflicts
> would result from a user not understanding this.

As I said in an earlier post, I do use two systems (chnset and outvalue)
in the same orchestra. The important difference is that one is a
software bus and the other just calls my callback directly with an ID
string and a value.

-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

 > As I said in an earlier post, I do use two systems (chnset and outvalue)
 > in the same orchestra. The important difference is that one is a

This is a rare case but nonetheless a valid one. The issue at the moment 
is that there is no standard which means users have to rewrite their 
Csound code each time they want to run it with another GUI front end. 
For example a users of MacCsound who's want to build a GUI instrument 
that works both as a csLADSPA plugin and a MacCsound instrument cannot 
do so without employing lots of #ifdef. Another example would be users 
of Lettuce who want to port their work to MacCsound. At present this 
will not work without completely rewriting ones code. In an ideal world 
the following instrument would run as a csLADSPA, a MacCsound instrument 
and a Lettuce instrument without changing a line of code:

		;csLADSPA section
Name=Gain-Mono
Maker=John Doe
UniqueID=1054
Copyright=GNU
ControlPort=Gain|gain
Range=0|2
		;Lettuce section

form "Untitled", 300, 250, 10, 10
menu "menu_0", 0, TopItem:"File",  RunCsound:"Start_Csound|Stop_Csound", 
  StdOut:"View_Console",  Exit:"Close"
scrollbar "gain", 100, 17, 33, 40, 0, 100, 0, "horizontal"

Name=Gain-Mono
Maker=John Doe
UniqueID=1054
Copyright=GNU
ControlPort=Gain|gain
Range=0|2

		;MacCsound sectin
//I don't have a Mac!!
//In here would be the relevant MacCsound code



/*Lettuce declared channels, do not code manually between these comments*/
/*end of channel declaration*/
sr = 44100
ksmps = 64
nchnls = 1

instr 1
	kGain chnget "gain"
	ain inch 1
	out ain*kGain
endin



i1 0 3600




One obvious problem with the code presented above is that it's rather 
cumbersome. After meeting Matt at Sounds Electric in November we started 
to discuss the idea of developing an attribute based bussing system on 
the premise that most front-ends use common components such as 
scrollbars, buttons, comboboxes etc. For example, below we have a 
hypothetical "allocwidget" opcode that creates a new channel and widget. 
It also allows users to dynamically change widgets, if the host supports 
such a thing.

; allocates widget and returns
; 2 buschannel variables,
; one for the value, one for the attributes
; all input attribute text is optional and
gkvl1, gSa1 allocwidget "type(slider) channel(freq) size(100, 100) 
colour(red) value(50)"

; real-time changing of the widget
instr 1
   printk gkv1 ; print current value of the widget
   gkv1 = .2 ; sets the value of the widget
   gSa1 = "value(.2) ; this does the same thing
   gSa1 = "size(50, 50)"; change the size of the widget
endin

With such a system the multi-frontend Csound code presented above could 
be reduced in size to this:



/*Lettuce declared channels, do not code manually between these comments*/
/*end of channel declaration*/
sr = 44100
ksmps = 64
nchnls = 1

gkvl1, gSa1 allocwidget "type(slider) channel("gain") size(100, 100) 
position(10, 10) value(0)"

instr 1
	ain inch 1
	out ain*gkvl1
endin



i1 0 3600



With the development of more and more GUI frontends I think now is the 
time to starting thinking about such a system. What do others think?

Rory.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I haven't really thought about layout but it would be nice for size, 
colour, min/max ranges and things like that. If a front-end allowed it's 
widgets to change during performance then users could create their own 
custom widgets. A simple example would be a peak-level indicator, a 
panel that would simply change colour whenever the signal clips. A 
"hidden" attribute could hide controls until they are needed. Users 
could design their own audio level meters by stacking some panels on top 
of each-other and having them change colour according to the levels.

Rory.



Oeyvind Brandtsegg wrote:
> It is an interesting idea, I like it,
> but how (possibly also why) would you control widget layout from within Csound ?
> Oeyvind
> 
> 2008/1/26, Rory Walsh :
>>  > As I said in an earlier post, I do use two systems (chnset and outvalue)
>>  > in the same orchestra. The important difference is that one is a
>>
>> This is a rare case but nonetheless a valid one. The issue at the moment
>> is that there is no standard which means users have to rewrite their
>> Cso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Rory Walsh wrote:
>  > As I said in an earlier post, I do use two systems (chnset and outvalue)
>  > in the same orchestra. The important difference is that one is a
> 
> This is a rare case but nonetheless a valid one. The issue at the moment 
> is that there is no standard which means users have to rewrite their 
> Csound code each time they want to run it with another GUI front end. 
> For example a users of MacCsound who's want to build a GUI instrument 
> that works both as a csLADSPA plugin and a MacCsound instrument cannot 
> do so without employing lots of #ifdef. Another example would be users 
> of Lettuce who want to port their work to MacCsound. At present this 
> will not work without completely rewriting ones code. In an ideal world 
> the following instrument would run as a csLADSPA, a MacCsound instrument 
> and a Lettuce instrument without changing a line of code:
...snip...
> One obvious problem with the code presented above is that it's rather 
> cumbersome. After meeting Matt at Sounds Electric in November we started 
> to discuss the idea of developing an attribute based bussing system on 
> the premise that most front-ends use common components such as 
> scrollbars, buttons, comboboxes etc. For example, below we have a 
> hypothetical "allocwidget" opcode that creates a new channel and widget. 
> It also allows users to dynamically change widgets, if the host supports 
> such a thing.
...snip...
> With such a system the multi-frontend Csound code presented above could 
> be reduced in size to this:
> 
> 
> 
> /*Lettuce declared channels, do not code manually between these comments*/
> /*end of channel declaration*/
> sr = 44100
> ksmps = 64
> nchnls = 1
> 
> gkvl1, gSa1 allocwidget "type(slider) channel("gain") size(100, 100) 
> position(10, 10) value(0)"
> 
> instr 1
> 	ain inch 1
> 	out ain*gkvl1
> endin
> 
> 
> 
> i1 0 3600
> 
> 
> 
> With the development of more and more GUI frontends I think now is the 
> time to starting thinking about such a system. What do others think?

Sure, but there's also cases where the input isn't a typical GUI widget.
(For example in my host app, the signal probably comes from some
graphical curve or algorithmic generator of some sort).

For standardized GUI building, I think it would be better to use a more
abstract way of I/O in the orchestra (like invalue or software busses)
and have a separate layer for the GUI. It could be a simple XML file
that creates widgets (and even does the layout) and associates them with
channels for invalue or getchn...  Then different GUI frontends could
parse this XML.

Something like this for the example above:


  



  sr = 44100
  ksmps = 64
  nchnls = 1

  gkvl1 chnexport "gain", 1

  instr 1
    ain inch 1
    out ain*gkvl1
  endin


The point is not to have GUI specific stuff in the orchestra. The
instrument above could as well be controlled non-realtime from a
graphical score host application (like my AlgoScore) or from a real-time
user interface created from the given UI definition...

-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Jan 28, 2008, at 8:13 AM, Jonatan Liljedahl wrote:

> For standardized GUI building, I think it would be better to use a  
> more
> abstract way of I/O in the orchestra (like invalue or software busses)
> and have a separate layer for the GUI. It could be a simple XML file
> that creates widgets (and even does the layout) and associates them  
> with
> channels for invalue or getchn...  Then different GUI frontends could
> parse this XML.


this is pretty much what we are talking about -- the "allocwidget"  
opcode
idea Rory posted was really just be a "convenience" opcode that actually
internally just called the host via the API ( ala "outvalue" or  
whatever..  )


matt ingalls
development@gvox.com




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>
> As I said in an earlier post, I do use two systems (chnset and  
> outvalue)
> in the same orchestra. The important difference is that one is a
> software bus and the other just calls my callback directly with an ID
> string and a value.

what i am proposing would be to merge the 2 systems so both always use  
the
  internal "channel list" within Csound but also makes the callback to  
the host
(if the host has registered one)

matt ingalls
development@gvox.com




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> 
>      position="10,10" value=0 />
> 
> 
> 
>   sr = 44100
>   ksmps = 64
>   nchnls = 1
> 
>   gkvl1 chnexport "gain", 1
> 
>   instr 1
>     ain inch 1
>     out ain*gkvl1
>   endin
> 
> 
> The point is not to have GUI specific stuff in the orchestra. The
> instrument above could as well be controlled non-realtime from a
> graphical score host application (like my AlgoScore) or from a real-time
> user interface created from the given UI definition...

This is the way Lettuce currently works although the syntax is slightly 
different. The nice thing about having an opcode to set up GUI and 
channel stuff would be that users could create simple loops to build a 
row of sliders, or a row of buttons for example. They could build UDO's 
that would create custom arrangements of widgets, something that is 
quite cumbersome with XML. I also see the point your making, i.e., what 
if the host doesn't have any kind of GUI elements but works in a 
different way? 'allocwidget' still sets up a named channel that you can 
communicate on. In that case however 'allocwidget' would be a slightly 
misleading name. I need to think about this.

Rory.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Rory Walsh wrote:
>> 
>>   >   position="10,10" value=0 />
>> 
>>
>> 
>>   sr = 44100
>>   ksmps = 64
>>   nchnls = 1
>>
>>   gkvl1 chnexport "gain", 1
>>
>>   instr 1
>>     ain inch 1
>>     out ain*gkvl1
>>   endin
>> 
>>
>> The point is not to have GUI specific stuff in the orchestra. The
>> instrument above could as well be controlled non-realtime from a
>> graphical score host application (like my AlgoScore) or from a real-time
>> user interface created from the given UI definition...
> 
> This is the way Lettuce currently works although the syntax is slightly 
> different. The nice thing about having an opcode to set up GUI and 
> channel stuff would be that users could create simple loops to build a 
> row of sliders, or a row of buttons for example. They could build UDO's 
> that would create custom arrangements of widgets, something that is 
> quite cumbersome with XML. I also see the point your making, i.e., what 
> if the host doesn't have any kind of GUI elements but works in a 
> different way? 'allocwidget' still sets up a named channel that you can 
> communicate on. In that case however 'allocwidget' would be a slightly 
> misleading name. I need to think about this.

Yes, you have a point there, it's nice to be able to create widgets in
loops and stuff like that. And even dynamically if that makes sense.
I don't know, I just got a feeling that programming UI stuff doesn't
feel right in csound orchestra code... (especially purely visual stuff
like the shape and color of widgets).

But sure, there already is opcodes for specific GUI widgets, it would be
a lot better if they were standardized and not associated with a
specific host or graphical toolkit!

I think my idea is to have a more abstract definition of ins and outs,
perhaps with attributes to decide what type and range a channel is (like
boolean, or 0-127 integer, or -1 to +1 floating point, etc..) and then
this can be driven with different kinds of UI: non-interactive from
external app (Max, PureData, AlgoScore), interactive GUI widgets from a
frontend, or external hardware controllers (MIDI, OSC, or whatever).


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

matt ingalls wrote:
>> As I said in an earlier post, I do use two systems (chnset and  
>> outvalue)
>> in the same orchestra. The important difference is that one is a
>> software bus and the other just calls my callback directly with an ID
>> string and a value.
> 
> what i am proposing would be to merge the 2 systems so both always use  
> the
>   internal "channel list" within Csound but also makes the callback to  
> the host
> (if the host has registered one)

But then there would be no difference between them. Sometimes it's best
to read/write the value in a controlled way directly after
performKsmps(), and sometimes you want a callback-based system where
'outvalue "foo", 42' directly calls a function in my host.
Sure, as long as you want to use only one of these methods it's no
problem, but if you need both then it will be a problem.

Also it's really useful that the callbacks is called directly with
outvalue, so one can send multiple values (even on the same "channel")
in the same k-rate cycle.

I use the two systems for totally different purposes: chnget to send
global control data from my graphical score to csound, and outvalue to
send event-specific data for plotting of envelopes etc.
(Merging the two systems would really complicate things for me.)

There's another important difference in that outvalue/invalue doesn't
use a channel-list but simply passes a string to the callback to
identify the "channel". So you can send anything in this string and it's
up to the host to handle it, it doesn't create any internal memory-using
channels in csound itself.

So I really think it's good to keep these separate systems. But now
there are more than these two.. like chani/chano could perhaps be merged
with the chnget/chnset system? (if chnset/chnget could optionally take a
k-rate number instead of a string as channel name, but perhaps without
the auto-declaration of channels that the i-rate (?) string names does
now...)

-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>
> Sure, as long as you want to use only one of these methods it's no
> problem, but if you need both then it will be a problem.

i don't see how it would be a problem.  you would never *need* to use
both, as they would both work the same.

> There's another important difference in that outvalue/invalue doesn't
> use a channel-list but simply passes a string to the callback to
> identify the "channel". So you can send anything in this string and  
> it's
> up to the host to handle it, it doesn't create any internal memory- 
> using
> channels in csound itself.

well you do have a point there, although i would think most hosts would
be doing memory allocation anyway -- mine certainly does!

matt ingalls
development@gvox.com




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

matt ingalls wrote:
>> Sure, as long as you want to use only one of these methods it's no
>> problem, but if you need both then it will be a problem.
> 
> i don't see how it would be a problem.  you would never *need* to use
> both, as they would both work the same.

I meant that if one needs to use direct access (reading/writing through
pointer or function after each k-rate cycle) for some things and
callback access (reading/writing values each time invalue/outvalue is
called) for other things, but in the same host and at the same time,
then there's a problem if there's only one system that does both ways,
since you cannot separate them.

>> There's another important difference in that outvalue/invalue doesn't
>> use a channel-list but simply passes a string to the callback to
>> identify the "channel". So you can send anything in this string and  
>> it's
>> up to the host to handle it, it doesn't create any internal memory- 
>> using
>> channels in csound itself.
> 
> well you do have a point there, although i would think most hosts would
> be doing memory allocation anyway -- mine certainly does!

Mine does not, sort of... The callback checks if the incoming "channel"
is in a list (user specified) of channels to plot and if so how to plot
them.

-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

matt ingalls wrote:
>>
>> I meant that if one needs to use direct access (reading/writing through
>> pointer or function after each k-rate cycle) for some things and
>> callback access (reading/writing values each time invalue/outvalue is
>> called) for other things, but in the same host and at the same time,
>> then there's a problem if there's only one system that does both ways,
>> since you cannot separate them.
> 
> i still can't think of how this would create a conflict in general use.  
> 
> if you are doing crazy things (and writing a host to handle it)
> you probably would want to use something else anyway
> - like registering a callback with csoundSetCallback
> ( and creating a new opcode to call it??? )

Yes, I do crazy things. :)
What I use outvalue for is to send data specific for individual
instrument instances, to be able to plot data graphically (like their
amplitude envelope or whatever).

1) I make my host tag all instrument events (fractional part of p1) and
keep a list of them.

2) The instrument sends it's p1 on the "tag" channel, which the host
recognizes and remembers.

3) Then right after it sends all values that should be plotted, which
the host now knows what instrument instance they belong to.

This is really hackish and I don't like that I need to tag each event
like this... What I *really* would like is that csoundScoreEvent()
returned a pointer or ID of that particular event, and that the
draw-graph-callback (as set with csoundSetDrawGraphCallback()) was
passed this ID somehow so the host knows what instrument event that this
"display" was called in. Even better if also the outvalue/invalue
callbacks was passed this ID!

In the future, I would love to also be able to pass control-data from my
host app to specific instrument events and not to global busses. So in
practice it would be like local channels. If instr 1 gets a value with
invalue "amp", then my host would know _which_ instance of instr 1 that
is asking for an amp value! (and preferably also what point in time,
even though I guess my host could keep track of that with a counter...)

Perhaps this ID/pointer could be passed in the CSOUND struct since this
is already passed to all functions? Something like cs->event_id.. Or
perhaps it already is there somewhere??

-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yeah, that would probably work.

But it would be nice if I didn't need to use the tagging of p1, but that
csoundScoreEvent() returned an ID or the pointer to the event.

Oeyvind Brandtsegg wrote:
> Maybe you could create chn channels per instance, like this:
> 
> instance = frac(p1)
> S_amp	sprintf  "Amp_instance_%f", instance
> kamp 	chnget 	S_amp
> 
> Oeyvind
> 
> 2008/1/30, Jonatan Liljedahl :
>> In the future, I would love to also be able to pass control-data from my
>> host app to specific instrument events and not to global busses. So in
>> practice it would be like local channels. If instr 1 gets a value with
>> invalue "amp", then my host would know _which_ instance of instr 1 that
>> is asking for an amp value! (and preferably also what point in time,
>> even though I guess my host could keep track of that with a counter...)


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net