t score statement in .orc
Date | 2007-08-24 11:15 |
From | Alex Drader |
Subject | t score statement in .orc |
Is there no way to dynamically change the parameters of the tempo statement inside the .orc I've tried event and scoreline (which won't allow it). I'm trying to create a way to midi mix my music using two instances of csound. I have a controller that can crossfade and dj/mix... but I can't find a way to pitch-shift/switch the tempo of a whole song at any time. Get news delivered with the All new Yahoo! Mail. Enjoy RSS feeds right on your Mail page. Start today at http://mrd.mail.yahoo.com/try_beta?.intl=ca |
Date | 2007-08-24 14:39 |
From | Jacob Joaquin |
Subject | Re: t score statement in .orc |
You can use the -t flag to run Csound in beat mode. From there, I'm not certain of what you would need to make your setup work. You might try creating an instr that uses the tempo opcode to make realtime tempo changes, and call it as you need it. Here's an example: instr 1 tempo p4, 60 endin I've had issues with beat mode, as I suspect there are a few unresolved issues with its implementation. I created a .csd that demonstrates some of the potential bugs I've found with beat mode: http://www.thumbuki.com/csound/files/mailinglist/flag_t_test.csd Hope this helps. Best, Jake ---- The Csound Blog http://www.thumbuki.com/csound/blog Uduak wrote: > > Is there no way to dynamically change the parameters of the tempo > statement inside the .orc I've tried event and scoreline (which won't > allow it). I'm trying to create a way to midi mix my music using two > instances of csound. I have a controller that can crossfade and > dj/mix... but I can't find a way to pitch-shift/switch the tempo of a > whole song at any time. > > > Get news delivered with the All new Yahoo! Mail. Enjoy RSS feeds > right on your Mail page. Start today at > http://mrd.mail.yahoo.com/try_beta?.intl=ca > -- > Send bugs reports to this list. > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk > > -- View this message in context: http://www.nabble.com/t-score-statement-in-.orc-tf4322804.html#a12312624 Sent from the Csound - General mailing list archive at Nabble.com. |
Date | 2007-08-24 21:22 |
From | Alex Drader |
Subject | Re: t score statement in .orc |
Thanks for the info. I did try the beat mode and it's exactly what I needed... If it worked. I thought that because I was using the scoreline function that somehow that was what caused the changes to not work, but it doesn't seem to matter (I've tried all sorts of combinations). I don't understand. tempoval displays the changed tempo, and yet it doesn't work. Not one thing I'm trying is going through correctly, and your examples show the same thing. And it's just that this is so important right now it's making me angry, cause there seems to be no other way for me to change the tempo at any time. Is there any way you/or anyone could somehow take a look at the code and see if there is a quick fix. It's just that this is so important right now, that it's brought me to a swift stand-still. --- Jacob Joaquin |
Date | 2007-08-25 18:16 |
From | Greg Thompson |
Subject | Re: t score statement in .orc |
The tempo functionality in Csound is not adequate .. I would venture to say it does not work well enough for any useful application. I ran up against this problem a few weeks ago. I ended up writing my own sequencer around Csound. I guess there isn't enough demand for this type of thing to be fixed. While I'm at it - I will also continue to encourage the following improvements: - MIDI File opcodes (such that multiple MIDI files can be dynamically read in and performed in various ways within one instance of Csound) - separating control rate from sequencing resolution - so ksmps = 1 is not necessary. Basically, I feel the entire sequencing engine needs to be redesigned with realtime considerations built in. greg On Aug 24, 2007, at 4:22 PM, Alex Drader wrote: > Thanks for the info. I did try the beat mode and it's exactly what I > needed... If it worked. I thought that because I was using the > scoreline function that somehow that was what caused the changes to > not > work, but it doesn't seem to matter (I've tried all sorts of > combinations). I don't understand. tempoval displays the changed > tempo, and yet it doesn't work. Not one thing I'm trying is going > through correctly, and your examples show the same thing. And it's > just that this is so important right now it's making me angry, cause > there seems to be no other way for me to change the tempo at any time. > Is there any way you/or anyone could somehow take a look at the code > and see if there is a quick fix. It's just that this is so important > right now, that it's brought me to a swift stand-still. > > > > > --- Jacob Joaquin |
Date | 2007-08-25 18:32 |
From | Jeremy Flores |
Subject | Re: t score statement in .orc |
woot. also, you know if an elliptic filter has a sound very distinctive from chebyshev? i was trying to use this opcode in csound called clfilt that gives you the option for butterworth, chebyshev 1 and 2, or elliptic, but they haven't implemented the elliptic stuff yet. just wondering if it's worth emailing the list to request this. i hope you're doing more this weekend than csound, man :p jeremy Greg Thompson wrote: > The tempo functionality in Csound is not adequate .. I would venture > to say it does not work well enough for any useful application. I ran > up against this problem a few weeks ago. I ended up writing my own > sequencer around Csound. I guess there isn't enough demand for this > type of thing to be fixed. While I'm at it - I will also continue to > encourage the following improvements: > > - MIDI File opcodes (such that multiple MIDI files can be dynamically > read in and performed in various ways within one instance of Csound) > - separating control rate from sequencing resolution - so ksmps = 1 is > not necessary. Basically, I feel the entire sequencing engine needs > to be redesigned with realtime considerations built in. > > greg > > On Aug 24, 2007, at 4:22 PM, Alex Drader wrote: > >> Thanks for the info. I did try the beat mode and it's exactly what I >> needed... If it worked. I thought that because I was using the >> scoreline function that somehow that was what caused the changes to not >> work, but it doesn't seem to matter (I've tried all sorts of >> combinations). I don't understand. tempoval displays the changed >> tempo, and yet it doesn't work. Not one thing I'm trying is going >> through correctly, and your examples show the same thing. And it's >> just that this is so important right now it's making me angry, cause >> there seems to be no other way for me to change the tempo at any time. >> Is there any way you/or anyone could somehow take a look at the code >> and see if there is a quick fix. It's just that this is so important >> right now, that it's brought me to a swift stand-still. >> >> >> >> >> --- Jacob Joaquin |
Date | 2007-08-25 18:35 |
From | Jeremy Flores |
Subject | i'm an idiot |
sorry all, i just sent this to the wrong email address. oh well... Jeremy Flores wrote: > woot. > > also, you know if an elliptic filter has a sound very distinctive from > chebyshev? i was trying to use this opcode in csound called clfilt > that gives you the option for butterworth, chebyshev 1 and 2, or > elliptic, but they haven't implemented the elliptic stuff yet. > > just wondering if it's worth emailing the list to request this. > > i hope you're doing more this weekend than csound, man :p > > jeremy > > > > > Greg Thompson wrote: >> The tempo functionality in Csound is not adequate .. I would venture >> to say it does not work well enough for any useful application. I >> ran up against this problem a few weeks ago. I ended up writing my >> own sequencer around Csound. I guess there isn't enough demand for >> this type of thing to be fixed. While I'm at it - I will also >> continue to encourage the following improvements: >> >> - MIDI File opcodes (such that multiple MIDI files can be dynamically >> read in and performed in various ways within one instance of Csound) >> - separating control rate from sequencing resolution - so ksmps = 1 >> is not necessary. Basically, I feel the entire sequencing engine >> needs to be redesigned with realtime considerations built in. >> >> greg >> >> On Aug 24, 2007, at 4:22 PM, Alex Drader wrote: >> >>> Thanks for the info. I did try the beat mode and it's exactly what I >>> needed... If it worked. I thought that because I was using the >>> scoreline function that somehow that was what caused the changes to not >>> work, but it doesn't seem to matter (I've tried all sorts of >>> combinations). I don't understand. tempoval displays the changed >>> tempo, and yet it doesn't work. Not one thing I'm trying is going >>> through correctly, and your examples show the same thing. And it's >>> just that this is so important right now it's making me angry, cause >>> there seems to be no other way for me to change the tempo at any time. >>> Is there any way you/or anyone could somehow take a look at the code >>> and see if there is a quick fix. It's just that this is so important >>> right now, that it's brought me to a swift stand-still. >>> >>> >>> >>> >>> --- Jacob Joaquin |
Date | 2007-08-26 00:07 |
From | Greg Thompson |
Subject | Re: parameter interpolation |
gisin ftgen 0, 0, 4096, 10, 1, 0.5, 0.25, 0.125, 0.0625, 0.03125, 0.015625 instr 10 iBasePitch = p4 kFreePitch chnget "Pitch" kAmpChannel chnget "Amp" kPitch = cpspch(iBasePitch + kFreePitch) aAmp interp kAmpChannel aAmp = ampdbfs(aAmp) kEnv line 1.0, p3, 0.0 a1 oscili aAmp * kEnv, kPitch, gisin outs a1, a1 endin So, I have a slider representing pitch and amplitude. I'm using channels to pass values into the orchestra. So, in this case, I'm using the chnget opcode. I'm wondering how I do some simple form of interpolation so if I get a value of 1.0 at time t1 and then 2.0 at time t2. It gradual shifts from 1.0 to 2.0 over a slew time. In Max, I would use the line object. Can one suggest a proper way to do this in Csound? thanks greg |
Date | 2007-08-26 00:18 |
From | "Oeyvind Brandtsegg" |
Subject | Re: parameter interpolation |
Attachments | None |
Date | 2007-08-26 00:31 |
From | Greg Thompson |
Subject | Re: parameter interpolation |
Thanks - portk works for now. I figured I could just use a control rate filter. Wanted to make sure I wasn't overlooking anything. Yikes, are you suggesting bundling reinits in UDOs? That sounds like some nasty code. :) thanks greg On Aug 25, 2007, at 7:18 PM, Oeyvind Brandtsegg wrote: > The simplest way is to use portk or tonek. > This won't give you a linear sweep though, > for that you would use a line opcode and reinit, admittedly a bit > kludgy but could maybe be put into a UDO (if there's not one tht does > this already). > Oeyvind > > > 2007/8/26, Greg Thompson |
Date | 2007-08-26 00:49 |
From | Greg Thompson |
Subject | Re: parameter interpolation |
Okay I spoke too soon (as usual). The problem seems that because of the memory of the filter, I have to initialize it. So, I tried the following, which almost seems to be what I want: Obviously, if I don't specify the initial value and kFreePitch is > 0 it will slew up to the value for every event. kFreePitch portk kFreePitch, 0.5, i(kFreePitch) gisin ftgen 0, 0, 4096, 10, 1, 0.5, 0.25, 0.125, 0.0625, 0.03125, 0.015625 instr 10 iBasePitch = p4 kFreePitch chnget "Pitch" kAmpChannel chnget "Amp" kFreePitch portk kFreePitch, 0.5, i(kFreePitch) kPitch = cpspch(iBasePitch + kFreePitch) aAmp interp kAmpChannel aAmp = ampdbfs(aAmp) kEnv line 1.0, p3, 0.0 a1 oscili aAmp * kEnv, kPitch, gisin outs a1, a1 greg On Aug 25, 2007, at 7:31 PM, Greg Thompson wrote:
|
Date | 2007-08-26 20:29 |
From | Erik Spjut |
Subject | Re: i'm an idiot |
I'm the guilty party. I can't guarantee when I'll get back to this, but it won't be any time soon. I do plan on adding elliptical as well as bandpass and band block. On Aug 25, 2007, at 10:35 AM, Jeremy Flores wrote: > sorry all, i just sent this to the wrong email address. oh well... > > > Jeremy Flores wrote: >> woot. >> >> also, you know if an elliptic filter has a sound very distinctive >> from chebyshev? i was trying to use this opcode in csound called >> clfilt that gives you the option for butterworth, chebyshev 1 and >> 2, or elliptic, but they haven't implemented the elliptic stuff yet. >> >> just wondering if it's worth emailing the list to request this. >> >> i hope you're doing more this weekend than csound, man :p >> >> jeremy >> >> >> >> >> Greg Thompson wrote: >>> The tempo functionality in Csound is not adequate .. I would >>> venture to say it does not work well enough for any useful >>> application. I ran up against this problem a few weeks ago. I >>> ended up writing my own sequencer around Csound. I guess there >>> isn't enough demand for this type of thing to be fixed. While I'm >>> at it - I will also continue to encourage the following >>> improvements: >>> >>> - MIDI File opcodes (such that multiple MIDI files can be >>> dynamically read in and performed in various ways within one >>> instance of Csound) >>> - separating control rate from sequencing resolution - so ksmps = >>> 1 is not necessary. Basically, I feel the entire sequencing >>> engine needs to be redesigned with realtime considerations built in. >>> >>> greg >>> >>> On Aug 24, 2007, at 4:22 PM, Alex Drader wrote: >>> >>>> Thanks for the info. I did try the beat mode and it's exactly >>>> what I >>>> needed... If it worked. I thought that because I was using the >>>> scoreline function that somehow that was what caused the changes >>>> to not >>>> work, but it doesn't seem to matter (I've tried all sorts of >>>> combinations). I don't understand. tempoval displays the changed >>>> tempo, and yet it doesn't work. Not one thing I'm trying is going >>>> through correctly, and your examples show the same thing. And it's >>>> just that this is so important right now it's making me angry, >>>> cause >>>> there seems to be no other way for me to change the tempo at any >>>> time. >>>> Is there any way you/or anyone could somehow take a look at the >>>> code >>>> and see if there is a quick fix. It's just that this is so >>>> important >>>> right now, that it's brought me to a swift stand-still. >>>> >>>> >>>> >>>> >>>> --- Jacob Joaquin |
Date | 2007-08-27 12:30 |
From | Victor Lazzarini |
Subject | Re: t score statement in .orc |
But with the default ksmps=10, any inaccuracy is only 10/44100 = 0.226 ms, which is beyond anyone's perception. With ksmps=10, Csound runs quite efficiently. Redesigning the engine to have sample accuracy would involve re-writing much of it. I can't see the gain. And the efficiency might be lost (say if we were designing some sort of multi-threaded solution) for certain CPUs (say single-processor ones. I agree that multiple MIDI files are desirable. It is not too difficult, I had a look at it, but it requires some changes to the CSOUND class and probably an API version increment. Definitely for one the next releases. Victor At 18:16 25/08/2007, you wrote: >The tempo functionality in Csound is not adequate .. I would venture >to say it does not work well enough for any useful application. I >ran up against this problem a few weeks ago. I ended up writing my >own sequencer around Csound. I guess there isn't enough demand for >this type of thing to be fixed. While I'm at it - I will also >continue to encourage the following improvements: > >- MIDI File opcodes (such that multiple MIDI files can be dynamically >read in and performed in various ways within one instance of Csound) >- separating control rate from sequencing resolution - so ksmps = 1 >is not necessary. Basically, I feel the entire sequencing engine >needs to be redesigned with realtime considerations built in. > >greg > >On Aug 24, 2007, at 4:22 PM, Alex Drader wrote: > >>Thanks for the info. I did try the beat mode and it's exactly what I >>needed... If it worked. I thought that because I was using the >>scoreline function that somehow that was what caused the changes to >>not >>work, but it doesn't seem to matter (I've tried all sorts of >>combinations). I don't understand. tempoval displays the changed >>tempo, and yet it doesn't work. Not one thing I'm trying is going >>through correctly, and your examples show the same thing. And it's >>just that this is so important right now it's making me angry, cause >>there seems to be no other way for me to change the tempo at any time. >>Is there any way you/or anyone could somehow take a look at the code >>and see if there is a quick fix. It's just that this is so important >>right now, that it's brought me to a swift stand-still. >> >> >> >> >>--- Jacob Joaquin |