Re: [Cs-dev] opcode request - pgmin
| Date | 2006-06-09 15:49 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-09 16:42 |
| From | "Dr. Richard Boulanger" |
| Subject | [Cs-dev] opcode request - pgmin |
Dear Developers, I have a need for an opcode that would work like the max/msp external - pgmin ipgm, ichan pgmin Currently I am parsing my mid input using the midiin opcode and looking for status 192 and then using the data1 value to change the ipres parameter on the sfplay opcode, but it is not reliable - as seen below kstatus, kchan, kdata1, kdata2 midiin if (kstatus==192 && kchan==1) then ipres = i(kdata1) endif What I want is a way to directly map program change messages into my instrument (the sfplay opcode actually) without all these additional tests and use it to select samples from within a soundfont bank. What I am getting currently is a new program change for every note i play on the midi keyboard Hope one of you can help. -dB _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-09 16:53 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-09 17:33 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
here is the manpage for sfplay.... ar1, ar2 sfplay ivel, inotenum, xamp, xfreq, ipreindex [, iflag] [, ioffset] so... i have loaded in a general midi soundfontbank and I want to select from 127 preset instruments using program change messages from a standard midi controller and from a standard midi file but we do not currently have an opcode (such as in max/msp - pgmin) that reads in program change messages sent from a controller keyboard or midifile. as shown below, parsing with midiin does not work correctly because when i test for the program change status byte, it still passes data when other status bytes are received from the midi input I have it working fine if I use ctlin, but standard midi files use program change messages to change programs/patches/samples On Jun 9, 2006, at 10:49 AM, Istvan Varga wrote: > Exactly what is this opcode intended to do ? Also, you could > provide more details about your sfplay instrument: perhaps > what you want can be done easily without a new opcode. > > On Friday 09 June 2006 17:42, Dr. Richard Boulanger wrote: > >> ipgm, ichan pgmin >> >> Currently I am parsing my mid input using the midiin opcode and >> looking for status 192 and then using >> the data1 value to change the ipres parameter on the sfplay opcode, >> but it is not >> reliable - as seen below >> >> kstatus, kchan, kdata1, kdata2 midiin >> >> if (kstatus==192 && kchan==1) then >> ipres = i(kdata1) >> endif >> >> What I want is a way to directly map program change messages into my >> instrument (the sfplay opcode actually) >> without all these additional tests and use it to select samples from >> within a soundfont bank. >> >> What I am getting currently is a new program change for every note i >> play on the midi keyboard >> >> Hope one of you can help. > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-09 22:26 |
| From | David Akbari |
| Subject | Re: [Cs-dev] opcode request - pgmin |
Hiya Dr. B!
I think you had the right idea in your original post for sure with
the conditional checking of midiin. I made this [0] after reading and
thinking about this request / thread for a long time. This does what I
interpreted your original request to be in that since playing MIDI
notes on the keyboard makes new allocations for the instrument, it is
no problem to use the i(krate) in this situation. I had also tried
using event to try and fit the i-rate in there more directly, but ran
into problems. This solution seems much more pleasant.
In this patch, users are allowed to select which preset in a
soundfont to use directly (although perhaps care could be taken to
design an increment system using two buttons..) The program change
messages are used as an index to the preset contained in the soundfont.
It could be possible to improve this model by creating additional
effects and making some kind of preset system (Andres Cabrera had a
nice one in Diffamator for FLTK)
Performance notes; this uses CC's 07 ("relative" volume, eg *after*
velocity) and 01 a debug feature that tells you what preset you're
currently on if the wheel is more than half
turned/activated/pressed/ect. Use program change messages and play
notes for soundfont fun!
-David
[0]
|
| Date | 2006-06-10 12:34 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-10 13:27 |
| From | "David Akbari" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-10 14:36 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-10 14:51 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-10 15:29 |
| From | Dr.Richard Boulanger |
| Subject | Re: [Cs-dev] opcode request - pgmin |
David,
Thanks for this solution. I will be checking it out later this
evening and get back to you.
-dB
On Jun 9, 2006, at 5:26 PM, David Akbari wrote:
>
> Hiya Dr. B!
>
> I think you had the right idea in your original post for sure with
> the conditional checking of midiin. I made this [0] after reading and
> thinking about this request / thread for a long time. This does what I
> interpreted your original request to be in that since playing MIDI
> notes on the keyboard makes new allocations for the instrument, it is
> no problem to use the i(krate) in this situation. I had also tried
> using event to try and fit the i-rate in there more directly, but ran
> into problems. This solution seems much more pleasant.
>
> In this patch, users are allowed to select which preset in a
> soundfont to use directly (although perhaps care could be taken to
> design an increment system using two buttons..) The program change
> messages are used as an index to the preset contained in the
> soundfont.
> It could be possible to improve this model by creating additional
> effects and making some kind of preset system (Andres Cabrera had a
> nice one in Diffamator for FLTK)
>
> Performance notes; this uses CC's 07 ("relative" volume, eg *after*
> velocity) and 01 a debug feature that tells you what preset you're
> currently on if the wheel is more than half
> turned/activated/pressed/ect. Use program change messages and play
> notes for soundfont fun!
>
>
>
> -David
>
> [0]
>
> |
| Date | 2006-06-10 15:32 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
Istvan, thanks for the modifications to Csound and thanks for this solution. I will be checking this solution out tonight and hopefully using the new opcodes when I get back to MIT on Tuesday. -dr.B. On Jun 9, 2006, at 11:53 AM, Istvan Varga wrote: > It is still not quite clear what you mean, and I do not use Max/MSP. > However, am I guessing right that you want an opcode that returns > the currently set program (as a state) for a MIDI channel, rather > than the MIDI message only when it is received ? > > For example, the following opcode, which is similar to midichn, > would return the program number (1 to 128) for channel 'ichn' > (defaults to 0 which means the channel on which the current note > was activated), or zero for a score note: > > ipgm midipgm [ichn] > > Without a new opcode, you could store the preset number for each > channel in a table: > > ; always use instr 2 for MIDI notes > massign 0, 2 > pgmassign 0, 0 > > ; table for storing preset numbers, with defaults set below > ; table[0] is for score notes, table[1] is channel 1, etc. > giPresetTbl ftgen 0, 0, 33, -2, 1, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, > 11, 15, 16 > > ; instr 1 should be always on > instr 1 > > nxtEvt: > kst, kch, kd1, kd2 midiin > if (kst != 0) then > if (kst == 192) then > tablew kd1 + 1, kch, giPresetTbl > endif > ; add any other MIDI event parsing here > ; ... > endif > > endin > > instr 2 > > ichn midichn > ipreset table ichn, giPresetTbl > > ; generate sound output > ; ... > > endin > > On Friday 09 June 2006 18:33, Dr. Richard Boulanger wrote: > >> here is the manpage for sfplay.... >> >> ar1, ar2 sfplay ivel, inotenum, xamp, xfreq, ipreindex [, iflag] [, >> ioffset] >> >> so... i have loaded in a general midi soundfontbank and I want to >> select from 127 preset instruments >> using program change messages from a standard midi controller and >> from a standard midi file >> >> but we do not currently have an opcode (such as in max/msp - pgmin) >> that reads in program change messages >> sent from a controller keyboard or midifile. >> >> as shown below, parsing with midiin does not work correctly because >> when i test for the >> program change status byte, it still passes data when other status >> bytes are received from the midi input >> >> I have it working fine if I use ctlin, but standard midi files use >> program change messages to change programs/patches/samples > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-10 15:44 |
| From | Dr.Richard Boulanger |
| Subject | Re: [Cs-dev] opcode request - pgmin |
this opcode sounds perfect. - by default it should return program change messages from any channel, or you can optionally make the program change message channel specific. I would love it to be added, as well as the enhanced sensekey opcode too. hopefully they could be there before I work again at MIT on tuesday Dr. B. On Jun 10, 2006, at 9:36 AM, Istvan Varga wrote: > On Saturday 10 June 2006 16:32, Dr. Richard Boulanger wrote: > >> thanks for the modifications to Csound and thanks for this solution. >> I will be checking this solution out tonight and hopefully using >> the new >> opcodes when I get back to MIT on Tuesday. > > I did not add the new opcode yet, only asked if this is what you have > thought of. > >> On Jun 9, 2006, at 11:53 AM, Istvan Varga wrote: >> >>> It is still not quite clear what you mean, and I do not use Max/MSP. >>> However, am I guessing right that you want an opcode that returns >>> the currently set program (as a state) for a MIDI channel, rather >>> than the MIDI message only when it is received ? >>> >>> For example, the following opcode, which is similar to midichn, >>> would return the program number (1 to 128) for channel 'ichn' >>> (defaults to 0 which means the channel on which the current note >>> was activated), or zero for a score note: >>> >>> ipgm midipgm [ichn] > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-10 15:45 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-10 16:30 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
As I understand it, this pgmin opcode should work as an optimized subset of midiin. (just at notnum, and veloc) and I hope that you would not implement it in a fashion that it returned a new program change message every time a midi message or midi note was received becuase I think that this would cause all sorts of needless re-triggering. Rather, as in standard midi sequencers, when and only when a program change message is sent from the sequencer program (or from the synth), the receiving hardware or software synth (or the sfplay opcode in my case), should change to the new preset/ program. Once implemented, the new *pgmin* opcode should be a simple, direct and intuitive opcode that will help all MIDI musicians in their Csound instrument design and make the sfplay (and fluid) opcode(s) much more useful too. *pgmin* is a standard opcode/external in PD and Max/MSP and something that has been missing from Csound for a long time. i do imagine that it would be used exactly like notnum, and veloc, and would be as intuitive as midic7. having to do all the conditional stuff to parse the raw midi seems needlessly complicated and possibly less efficient. In fact, there is a great external for just this purpose in Max/MSP and PD that I think you should add too. It is called - midiparse it puts out all the midi messages as separate output arguments. noteon, noteoff, control, program, etc Its compliment, of course, is - midiformat we have something of this in Gabriel's midiout opcodes, but we were missing some of the midiin family -dB ps: maybe David Akbari would like to design midiparse and midiformat UDO's?? and... for that matter a pgmin and sensekey UDO if the opcode seems too difficult to add. Although, they are missing or poorly designed and do need to be there On Jun 10, 2006, at 9:51 AM, Istvan Varga wrote: > Again, I did not mean that the opcode would return program change > messages (which would be like midiin with a conditional), but rether > the currently set program for a channel or the current note (used > like notnum, veloc, midic7, etc.). Although the table based method > has the advantage that default preset numbers can be set in the table. > > On Saturday 10 June 2006 16:44, Dr.Richard Boulanger wrote: > >> this opcode sounds perfect. >> >> - by default it should return program change messages from any >> channel, or you can optionally >> make the program change message channel specific. >> >> I would love it to be added, as well as the enhanced sensekey opcode >> too. >> >> hopefully they could be there before I work again at MIT on tuesday > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-10 17:32 |
| From | matt ingalls |
| Subject | Re: [Cs-dev] opcode request - pgmin |
well the main difference to commercial synthesizers is that they are "always on" -- and it looked like to me in your code you use a traditional csound instrument, essentially allocating [ and "turning on" ] a new sfplay opcode for every new midi-on note. since sfplay's patch parameter is at i-rate, Istvan's opcode suggestion sounds like what you need. but if you want program changes done while you are playing a note, you probably will still have to use midiin and call reinit. perhaps a better solution to all this would be to add an option to sfplay [ or create a new opcode ] to 'listen to midi', which it could internally respond to all midi messages [ notes, channel pressure, patch changes, pitch bend, etc ], basically acting like a commercial midi synth? -m On Jun 10, 2006, at 7:45 AM, Istvan Varga wrote: > I am again getting very confused about what you really want. > > On Saturday 10 June 2006 17:30, Dr. Richard Boulanger wrote: > >> As I understand it, this pgmin opcode should work as an optimized >> subset of midiin. >> (just at notnum, and veloc) and I hope that you would not implement >> it in a fashion >> that it returned a new program change message every time a midi >> message or midi note >> was received becuase I think that this would cause all sorts of >> needless re-triggering. >> >> Rather, as in standard midi sequencers, when and only when a program >> change message >> is sent from the sequencer program (or from the synth), the receiving >> hardware or software synth >> (or the sfplay opcode in my case), should change to the new preset/ >> program. >> >> Once implemented, the new *pgmin* opcode should be a simple, direct >> and intuitive opcode that will >> help all MIDI musicians in their Csound instrument design and make >> the sfplay (and fluid) opcode(s) much >> more useful too. >> >> *pgmin* is a standard opcode/external in PD and Max/MSP and something >> that has been missing >> from Csound for a long time. >> >> i do imagine that it would be used exactly like notnum, and veloc, >> and would be as intuitive as midic7. >> >> having to do all the conditional stuff to parse the raw midi seems >> needlessly complicated and possibly less efficient. >> >> In fact, there is a great external for just this purpose in Max/MSP >> and PD that I think you should add too. >> >> It is called - midiparse >> >> it puts out all the midi messages as separate output arguments. >> noteon, noteoff, control, program, etc >> >> Its compliment, of course, is - midiformat >> >> we have something of this in Gabriel's midiout opcodes, but we were >> missing some of the midiin family >> >> -dB >> >> ps: maybe David Akbari would like to design midiparse and >> midiformat UDO's?? >> >> and... >> >> for that matter a pgmin and sensekey UDO if the opcode seems too >> difficult to add. >> >> Although, they are missing or poorly designed and do need to be there > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-10 21:58 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-10 22:51 |
| From | Dr.Richard Boulanger |
| Subject | Re: [Cs-dev] opcode request - pgmin |
a pgmin opcode On Jun 10, 2006, at 10:45 AM, Istvan Varga wrote: > I am again getting very confused about what you really want. > > On Saturday 10 June 2006 17:30, Dr. Richard Boulanger wrote: > >> As I understand it, this pgmin opcode should work as an optimized >> subset of midiin. >> (just at notnum, and veloc) and I hope that you would not implement >> it in a fashion >> that it returned a new program change message every time a midi >> message or midi note >> was received becuase I think that this would cause all sorts of >> needless re-triggering. >> >> Rather, as in standard midi sequencers, when and only when a program >> change message >> is sent from the sequencer program (or from the synth), the receiving >> hardware or software synth >> (or the sfplay opcode in my case), should change to the new preset/ >> program. >> >> Once implemented, the new *pgmin* opcode should be a simple, direct >> and intuitive opcode that will >> help all MIDI musicians in their Csound instrument design and make >> the sfplay (and fluid) opcode(s) much >> more useful too. >> >> *pgmin* is a standard opcode/external in PD and Max/MSP and something >> that has been missing >> from Csound for a long time. >> >> i do imagine that it would be used exactly like notnum, and veloc, >> and would be as intuitive as midic7. >> >> having to do all the conditional stuff to parse the raw midi seems >> needlessly complicated and possibly less efficient. >> >> In fact, there is a great external for just this purpose in Max/MSP >> and PD that I think you should add too. >> >> It is called - midiparse >> >> it puts out all the midi messages as separate output arguments. >> noteon, noteoff, control, program, etc >> >> Its compliment, of course, is - midiformat >> >> we have something of this in Gabriel's midiout opcodes, but we were >> missing some of the midiin family >> >> -dB >> >> ps: maybe David Akbari would like to design midiparse and >> midiformat UDO's?? >> >> and... >> >> for that matter a pgmin and sensekey UDO if the opcode seems too >> difficult to add. >> >> Although, they are missing or poorly designed and do need to be there > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-10 22:54 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
improving sfplay would be good, but I am happy if a pgmin opcode would respond to program change messages at irate. On Jun 10, 2006, at 12:32 PM, matt ingalls wrote: > well the main difference to commercial synthesizers is that they > are "always on" -- and it looked like to me in your code you use > a traditional csound instrument, essentially allocating [ and "turning > on" ] a new sfplay opcode for every new midi-on note. > > since sfplay's patch parameter is at i-rate, Istvan's opcode > suggestion > sounds like what you need. but if you want program changes done > while > you are playing a note, you probably will still have to use midiin > and call reinit. > > perhaps a better solution to all this would be to add an option to > sfplay > [ or create a new opcode ] to > 'listen to midi', which it could internally respond to all midi > messages > [ notes, channel pressure, patch changes, pitch bend, etc ], basically > acting like a commercial midi synth? > > -m > > On Jun 10, 2006, at 7:45 AM, Istvan Varga wrote: > >> I am again getting very confused about what you really want. >> >> On Saturday 10 June 2006 17:30, Dr. Richard Boulanger wrote: >> >>> As I understand it, this pgmin opcode should work as an optimized >>> subset of midiin. >>> (just at notnum, and veloc) and I hope that you would not implement >>> it in a fashion >>> that it returned a new program change message every time a midi >>> message or midi note >>> was received becuase I think that this would cause all sorts of >>> needless re-triggering. >>> >>> Rather, as in standard midi sequencers, when and only when a program >>> change message >>> is sent from the sequencer program (or from the synth), the >>> receiving >>> hardware or software synth >>> (or the sfplay opcode in my case), should change to the new preset/ >>> program. >>> >>> Once implemented, the new *pgmin* opcode should be a simple, direct >>> and intuitive opcode that will >>> help all MIDI musicians in their Csound instrument design and make >>> the sfplay (and fluid) opcode(s) much >>> more useful too. >>> >>> *pgmin* is a standard opcode/external in PD and Max/MSP and >>> something >>> that has been missing >>> from Csound for a long time. >>> >>> i do imagine that it would be used exactly like notnum, and veloc, >>> and would be as intuitive as midic7. >>> >>> having to do all the conditional stuff to parse the raw midi seems >>> needlessly complicated and possibly less efficient. >>> >>> In fact, there is a great external for just this purpose in Max/MSP >>> and PD that I think you should add too. >>> >>> It is called - midiparse >>> >>> it puts out all the midi messages as separate output arguments. >>> noteon, noteoff, control, program, etc >>> >>> Its compliment, of course, is - midiformat >>> >>> we have something of this in Gabriel's midiout opcodes, but we were >>> missing some of the midiin family >>> >>> -dB >>> >>> ps: maybe David Akbari would like to design midiparse and >>> midiformat UDO's?? >>> >>> and... >>> >>> for that matter a pgmin and sensekey UDO if the opcode seems too >>> difficult to add. >>> >>> Although, they are missing or poorly designed and do need to be >>> there >> >> >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel >> > > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-10 23:29 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
Thank you for implementing the new and improved opcodes, once I have and use them, I can let you know if they are working as they should and what might be needed or missing. Since you don't use MIDI, it is difficult to describe the exact behavior any better then my rather exact description of how the pgmin external works in Max/MSP and how any MIDI keyboard will work. Once again... When a program change message arrives from either a MIDIfile or a MIDI keyboard, the pgmin opcode should output the program number and optionally the channel number. also, as an optional input argument, there should be a setting that makes the opcode only output program change messages that are received on a specific midi channel. that is how I thought you had designed the opcode. -dB On Jun 10, 2006, at 4:58 PM, Istvan Varga wrote: > You still did not define its exact behavior, but anyway, I will add > the opcode I described earlier in 5.03. > > On Saturday 10 June 2006 23:51, Dr.Richard Boulanger wrote: > >> a pgmin opcode > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-11 01:57 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
I need the opcode today. Why won't it be in the bugfix release? and I need the sensekey opcode today. Why won't it be in the bugfix release? -dB On Jun 10, 2006, at 4:58 PM, Istvan Varga wrote: > You still did not define its exact behavior, but anyway, I will add > the opcode I described earlier in 5.03. > > On Saturday 10 June 2006 23:51, Dr.Richard Boulanger wrote: > >> a pgmin opcode > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-11 09:52 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-11 11:32 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
Thanks Istvan. I think that the midi opcode will also work exactly as I need and could make a huge difference in this time critical project. I am trying to install a clean Csound5 on my mac and still having a problem unstuffing Victor's latest release on my machine. I will work on that this morning too. -dB On Jun 11, 2006, at 4:52 AM, Istvan Varga wrote: > On Sunday 11 June 2006 02:57, Dr. Richard Boulanger wrote: > >> I need the opcode today. Why won't it be in the bugfix release? >> and I need the sensekey opcode today. Why won't it be in the bugfix >> release? > > Because a bugfix release is supposed to contain bug fixes, and not > new features like opcodes or API functions. However, the new sensekey > syntax is already included, but again, remember that the built-in > opcode is still limited, and only provides the syntax (so that > orchestras expecting the new behavior will at least compile and do > something) and not the actual full functionality. It is the job of > the frontend (e.g. MacCsound) to implement this in a way that > integrates well with its GUI. Also, API changes for the new sensekey > are not done yet for 5.02.1, but the opcode can be replaced until > 5.03 in the way I described. > I will add the MIDI program opcode later today for 5.03. > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-12 02:16 |
| From | matt ingalls |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None None |
| how are you changing the API? if you are going to change the API anyway, i would say leave sensekey as it was and instead add a 'sensekeyup' opcode and related API function. On Jun 11, 2006, at 1:52 AM, Istvan Varga wrote:
|
| Date | 2006-06-12 09:43 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-12 18:17 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-12 19:02 |
| From | matt ingalls |
| Subject | Re: [Cs-dev] opcode request - pgmin |
the callback does seem like the best way to do it -- definitely will make it easier to handle the buffering of data. would it be overkill if the callback is made even more open-ended? maybe something like: inputDeviceCallback(CSOUND *, int *dataType, float *value, int *modifiers); 'dataType' - code for value returned, keyDown, keyUp, mouseDown, mouseUp, etc.. 'value' - depends on dataType. ascii value for keys, (? -- left/ middle/right mousebutton) , etc.. 'modifiers' - any modifier keys pressed: option/cntrl/etc (or left/ middle/right mousebutton?) you also have x/y location for mouse clikcs, plus movement (location or delta) -- not to mention angle/distance/etc for graphics tablets, which might want to be considered here too?? maybe 'value' should then be a pointer to a struct instead, which could include 'modifiers', and all relevant value data... hmm... maybe we could just enhance the XYINDAT struct and use the xyin callbacks that are already there? but then how to get all that information out as an opcode(s)? -m On Jun 12, 2006, at 1:43 AM, Istvan Varga wrote: > On Monday 12 June 2006 03:16, matt ingalls wrote: > >> how are you changing the API? >> >> if you are going to change the API anyway, >> i would say leave sensekey as it was and instead add >> a 'sensekeyup' opcode and related API function. > > The changed sensekey opcode (with the optinal output argument) is > already in the 5.02.1 sources. However, I did not decide yet how > the API should be changed if using that is preferred over just > replacing the opcode from the host. The old csoundKeyPress() > function could be changed as you suggested earlier to interpret > key codes > 128 as key release, at the expense of limiting the > number of key codes that can be used to 127. Alternatively, a > new function could be added, either something like an extended > version of csoundKeyPress(), or a "sensekey callback". If a new > function is added, I would probably prefer the callback approach, > e.g. csoundSetSenseKeyCallback(CSOUND *, int (*func)(CSOUND *)), > as it leaves implementation details like buffering, thread > synchronization (if needed), etc. up to the host. Of course, one > could think of the idea of overriding the opcode as some sort of > "sensekey callback", too, a new API function is only more elegant > and avoids your specific problem of not being able to use csdl.h > (even if the latter would better be fixed anyway). > > However, currently I am waiting for the new Gogins 5.02 Win32 > installers before making any CVS changes; I already have some > uncommitted stuff. > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-12 20:05 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |
| Date | 2006-06-12 20:39 |
| From | matt ingalls |
| Subject | Re: [Cs-dev] opcode request - pgmin |
well i started liking the idea of just using XYINDAT, especially since i assume those functions are rarely used at the moment... but your new api function is OK -- i could see creating different opcodes where one might only request a 'KeyUp' type but another 'KeyUpOrDown' type or 'KeyOrMouse' type, etc... But a general function like this would be great to have a way to make new opcodes and have them communicate through the API without having to change the API at all. On Jun 12, 2006, at 10:17 AM, Istvan Varga wrote: > OK, then it will be a callback. The most generalized callback may be > something like: > int (*)(CSOUND *, void *datap, int type) > where 'datap' is a pointer to some kind of data (depending on the > 'type' parameter), and the return value depends on whether the > operation was successful, failed, or the type is unknown and thus > nothing was done. In fact, this approach allows for the same > callback to be used for many purposes, although at the cost of > some overhead. Also, if the callback can really be used for anything, > what should the name be ? > > On Monday 12 June 2006 20:02, matt ingalls wrote: > >> the callback does seem like the best way to do it >> -- definitely will make it easier to handle the buffering of data. >> >> would it be overkill if the callback is made even more open-ended? >> maybe something like: >> >> inputDeviceCallback(CSOUND *, int *dataType, float *value, int >> *modifiers); >> >> 'dataType' - code for value returned, keyDown, keyUp, mouseDown, >> mouseUp, etc.. >> 'value' - depends on dataType. ascii value for keys, (? -- left/ >> middle/right mousebutton) , etc.. >> 'modifiers' - any modifier keys pressed: option/cntrl/etc (or left/ >> middle/right mousebutton?) >> >> you also have x/y location for mouse clikcs, plus movement (location >> or delta) -- >> not to mention angle/distance/etc for graphics tablets, which might >> want to >> be considered here too?? maybe 'value' should then be a pointer to a >> struct instead, >> which could include 'modifiers', and all relevant value data... >> >> hmm... maybe we could just enhance the XYINDAT struct and use the >> xyin callbacks that are already there? >> >> but then how to get all that information out as an opcode(s)? > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-12 21:08 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
very excited by these possibilities - to support tablet, trackpad, mice, and xy in more robust and comprehensive and intuitive ways - as opcodes. -dB On Jun 12, 2006, at 2:02 PM, matt ingalls wrote: > the callback does seem like the best way to do it > -- definitely will make it easier to handle the buffering of data. > > would it be overkill if the callback is made even more open-ended? > maybe something like: > > inputDeviceCallback(CSOUND *, int *dataType, float *value, int > *modifiers); > > 'dataType' - code for value returned, keyDown, keyUp, mouseDown, > mouseUp, etc.. > 'value' - depends on dataType. ascii value for keys, (? -- left/ > middle/right mousebutton) , etc.. > 'modifiers' - any modifier keys pressed: option/cntrl/etc (or left/ > middle/right mousebutton?) > > you also have x/y location for mouse clikcs, plus movement (location > or delta) -- > not to mention angle/distance/etc for graphics tablets, which might > want to > be considered here too?? maybe 'value' should then be a pointer to a > struct instead, > which could include 'modifiers', and all relevant value data... > > hmm... maybe we could just enhance the XYINDAT struct and use the > xyin callbacks that are already there? > > but then how to get all that information out as an opcode(s)? > > > -m > > On Jun 12, 2006, at 1:43 AM, Istvan Varga wrote: > >> On Monday 12 June 2006 03:16, matt ingalls wrote: >> >>> how are you changing the API? >>> >>> if you are going to change the API anyway, >>> i would say leave sensekey as it was and instead add >>> a 'sensekeyup' opcode and related API function. >> >> The changed sensekey opcode (with the optinal output argument) is >> already in the 5.02.1 sources. However, I did not decide yet how >> the API should be changed if using that is preferred over just >> replacing the opcode from the host. The old csoundKeyPress() >> function could be changed as you suggested earlier to interpret >> key codes > 128 as key release, at the expense of limiting the >> number of key codes that can be used to 127. Alternatively, a >> new function could be added, either something like an extended >> version of csoundKeyPress(), or a "sensekey callback". If a new >> function is added, I would probably prefer the callback approach, >> e.g. csoundSetSenseKeyCallback(CSOUND *, int (*func)(CSOUND *)), >> as it leaves implementation details like buffering, thread >> synchronization (if needed), etc. up to the host. Of course, one >> could think of the idea of overriding the opcode as some sort of >> "sensekey callback", too, a new API function is only more elegant >> and avoids your specific problem of not being able to use csdl.h >> (even if the latter would better be fixed anyway). >> >> However, currently I am waiting for the new Gogins 5.02 Win32 >> installers before making any CVS changes; I already have some >> uncommitted stuff. >> >> >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel >> > > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-12 21:10 |
| From | "Dr. Richard Boulanger" |
| Subject | Re: [Cs-dev] opcode request - pgmin |
in max/msp and pd and junxion this type of external is call hi for human interface and it returns the data from any and all usb and other input devices. -dB On Jun 12, 2006, at 1:17 PM, Istvan Varga wrote: > OK, then it will be a callback. The most generalized callback may be > something like: > int (*)(CSOUND *, void *datap, int type) > where 'datap' is a pointer to some kind of data (depending on the > 'type' parameter), and the return value depends on whether the > operation was successful, failed, or the type is unknown and thus > nothing was done. In fact, this approach allows for the same > callback to be used for many purposes, although at the cost of > some overhead. Also, if the callback can really be used for anything, > what should the name be ? > > On Monday 12 June 2006 20:02, matt ingalls wrote: > >> the callback does seem like the best way to do it >> -- definitely will make it easier to handle the buffering of data. >> >> would it be overkill if the callback is made even more open-ended? >> maybe something like: >> >> inputDeviceCallback(CSOUND *, int *dataType, float *value, int >> *modifiers); >> >> 'dataType' - code for value returned, keyDown, keyUp, mouseDown, >> mouseUp, etc.. >> 'value' - depends on dataType. ascii value for keys, (? -- left/ >> middle/right mousebutton) , etc.. >> 'modifiers' - any modifier keys pressed: option/cntrl/etc (or left/ >> middle/right mousebutton?) >> >> you also have x/y location for mouse clikcs, plus movement (location >> or delta) -- >> not to mention angle/distance/etc for graphics tablets, which might >> want to >> be considered here too?? maybe 'value' should then be a pointer to a >> struct instead, >> which could include 'modifiers', and all relevant value data... >> >> hmm... maybe we could just enhance the XYINDAT struct and use the >> xyin callbacks that are already there? >> >> but then how to get all that information out as an opcode(s)? > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-12 21:18 |
| From | matt ingalls |
| Subject | Re: [Cs-dev] opcode request - pgmin |
well i meant through the API -- i was thinking it might be easy to add some extra elements in the struct for keypress, etc. the xyin opcode can just ignore them. On Jun 12, 2006, at 12:05 PM, Istvan Varga wrote: > On Monday 12 June 2006 21:39, matt ingalls wrote: > >> well i started liking the idea of just using XYINDAT, especially >> since i assume those functions are rarely used at the moment... > > They are used by the xyin opcode, and there is an implementation > in the widgets plugin. > > > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2006-06-13 14:24 |
| From | Istvan Varga |
| Subject | Re: [Cs-dev] opcode request - pgmin |
| Attachments | None |