[PD] Bidirectional Module Problem - dynamically changing delwrite?
Hello everyone again Can anyone lend me their brain for 5 minutes so I can get a second opinion of my problem? Essentially what I'm trying to do is create a *generic* module that links bi-directionally to other modules: send audio information and also receive it with minimal time delay. It is more easily understood by looking at this diagram: http://www-users.york.ac.uk/~kt503/pd/ID-specific-buffers.JPG (this example uses 'send'/'receive' but that's just so you get the idea, they're not appropriate as functions...) Given a line of connected modules, audio can be transmitted DOWN the signal chain easily, by simply connecting the modules. For audio going up the signal chain though there is difficulty:I had planned to implement a delread~ function in each module which is set to something like [delread~ $1-buffer] so that function A for instance has its own receive buffer (A-buffer), also make the blocksize 1 to minimize delay. However writing to these buffers is where I'm stuck- for a connected object I cannot dynamically alter a delwrite~, even though I can determine the name of the buffer (by receiving the name of the previous object in sequence) 'set..' is not supported for that function. I also tried throw~/catch~ objects, and I posted about this a few days ago. Throw will allow me to set it dynamically, however these functions do weird things at blocksizes other than 64! So I am stuck. Is there any way I can dynamically create/set a delwrite~? It seems to be the only function that might work in this case, and all that I need to do is change the destination. Or can anyone see another way i could realise the structure shown in the image? Alternatively, is this something that can be done with externals? I had hoped I wouldn't have to resort to them and i have no experiece at all in that department but this is crucial to my project. Any help would be greatly appreciated Regards, Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bidirectional Module Problem - dynamically changing delwrite?
Hi if you really want a settable [delwrite~], why don't you just use something like [set varname2( | [receive~ varname] | [delwrite~ fixedname] How exactly can this function as a settable delwrite~? no, you cannot dynamically change the [delwrite~] name, because [delwrite~] is the object that actually holds the delay line. Okay I understand... How about delread~ and vd~? If delwrite~ cannot be dynamically changed because it holds the delay line, then shouldn't the functions that read from it be more flexible? I have tested and they do not seem to respond to set :( Thanks for your help K On 5/15/07, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: Kim Taylor wrote: So I am stuck. Is there any way I can dynamically create/set a delwrite~? It seems to be the only function that might work in this no, you cannot dynamically change the [delwrite~] name, because [delwrite~] is the object that actually holds the delay line. all the [delread~]s and [vd~]s out there will depend on the existence of a named [delwrite~]. this is much the same as with [catch~]/[throw~] and [send~]/[receive~], so it follows the same logic: the object that would break everything when missing, cannot be made missing. pd does not impose much, but it tends to not allow you to create invalid dsp-graphs. case, and all that I need to do is change the destination. Or can anyone see another way i could realise the structure shown in the image? if you really want a settable [delwrite~], why don't you just use something like [set varname2( | [receive~ varname] | [delwrite~ fixedname] Alternatively, is this something that can be done with externals? I not if you prefer no segfaults. mfga.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bidirectional Module Problem - dynamically changing delwrite?
Oh I see... Sorry this isn't what I meant- I was looking to switch the assignments from delread/write objects. I wasn't really intending to use the delay to add a time delay, more that it's the only function that allows non-local connections which works at a reduced block size. I thought I might as well use send/receive and setting receive like you did here, but s/r don't work at lower block sizes unfortunately :( Thanks for your help anyway K On 5/15/07, Steffen [EMAIL PROTECTED] wrote: On 15/05/2007, at 19.10, Kim Taylor wrote: [set varname2( | [receive~ varname] | [delwrite~ fixedname] How exactly can this function as a settable delwrite~? Something along the line of the attached, i'm quite sure. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
Thanks that was a well written explanation, it makes much more sense now. I read the help for [block~] about the catch~/throw~ 'weirdness'. And although it says... Patches using send~/receive~ or throw~/catch~ to intercommunicate must have the same blocking... ...If I create a patch with [throw~ X] and [catch~ X] and [block~ 4] (all in the *same* patch, so presumably with the *same* blocking) I still get an output saying error: throw~ test: vector size mismatch How bizarre and frustrating! K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
Blocking is always done per canvas, that is, a [block~ X] in a subpatch will reblock that subpatch and all its siblings, however it will not reblock the surrounding parent patch. In the patch you've posted, you have two subpatches both with [block~ 1], but the surrounding patch still has the default 64-blocksize. If you try to send something between the two subpaches, they kind of have to pass through the land of [block~ 64] and that's something, Pd seems to dislike. I still get an output saying error: throw~ test: vector size mismatch How bizarre and frustrating! Is that maybe with a [dac~] or [adc~] in the same patch area? It's not possible to reblock parts of the patch that contain these objects. I thought of that.. I created a very simple patch with everything block~ 1, nothing connected... As soon as the program opens it gives errors. It seems to me that throw~/catch~ at blocksizes other than 64 acts weirdly, which is an awful shame because it was almost perfect for my purposes K #N canvas 185 276 462 312 12; #X obj 275 98 block~ 1; #N canvas 0 0 470 320 apple 0; #X obj 331 78 block~ 1; #X obj 44 87 catch~ apple1; #X obj 41 165 throw~ apple1; #X restore 64 81 pd apple; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
OK- after realising that throw~ can be set to different destinations and operate at lower blocksizes, I tried to make a 0 length feedback system using throw~ and catch~ See attachment or this link: http://www.zen26398.zen.co.uk/temp/throwcatchfeedback6.pd In this patch, a triangular excitation is sent first to dummy inlet of 'catchmod' (to force order) and then to 'throwmod'. The signal gets thrown to a catch in 'catchmod' and this abstraction outputs the signal to a table graph. The graph is written upon triggering, so it shows any delays in the system. It seems to work, however: I get error messages at the output- error: sigcatch A-test: unexpected vector size error: throw~ A-test: vector size mismatch I didn't get these with a default 64 bit blocksize. Why would the vector size be unexpected or mismatched for a blocksize of 1? Anyone know if this is a problem? K #N canvas 520 153 565 496 12; #X obj 35 24 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #N canvas 0 0 450 300 graph1 0; #X array banana 200 float 1; #A 0 0 0.193845 0.415825 0.641889 0.868545 0.866552 0.672418 0.450396 0.224325 0.0325599 0.00472592 0.000685946 9.95621e-005 1.4451e-005 2.0975e-006 3.04443e-007 4.41885e-008 6.41377e-009 9.3093e-010 1.3512e-010 1.96121e-011 2.84662e-012 4.13174e-013 5.99703e-014 8.70443e-015 1.26341e-015 1.83378e-016 2.66166e-017 3.86328e-018 5.60738e-019 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0; #X coords 0 1 199 -1 200 140 1; #X restore 266 28 graph; #X obj 42 443 tabwrite~ banana; #X obj 363 226 loadbang; #X msg 362 268 \; banana xticks 64 410 4 \; banana xlabel -1.1 64 \; pd dsp 1; #X floatatom 65 65 5 0.2 6 0 - - -; #N canvas 0 0 458 308 throwmod 0; #X obj 46 49 inlet~; #X obj 47 199 throw~ A-test; #X obj 352 75 block~ 1; #X connect 0 0 1 0; #X restore 82 294 pd throwmod; #N canvas 0 0 462 312 catchmod 0; #X obj 46 49 inlet~; #X obj 125 140 outlet~; #X obj 125 49 catch~ A-test; #X obj 284 267 block~ 1; #X connect 2 0 1 0; #X restore 80 248 pd catchmod; #N canvas 0 0 462 312 excitation 0; #X obj 62 462 outlet~; #X msg 43 297 0 \, 1 \$1; #X obj 118 267 pipe 20; #X obj 24 34 inlet; #X obj 59 375 vline~; #X floatatom 41 65 5 0 0 0 - - -; #X obj 68 421 lop~ 6000; #X obj 25 214 * 0.5; #X msg 134 296 0 \$1; #X text 68 35 - excitation width (ms); #X obj 38 140 f 0.5; #X connect 1 0 4 0; #X connect 2 0 8 0; #X connect 3 0 5 0; #X connect 3 0 10 0; #X connect 4 0 6 0; #X connect 6 0 0 0; #X connect 7 0 1 0; #X connect 7 0 2 1; #X connect 7 0 2 0; #X connect 8 0 4 0; #X connect 10 0 7 0; #X restore 53 155 pd excitation; #X text 112 66 width; #X connect 0 0 2 0; #X connect 0 0 8 0; #X connect 3 0 4 0; #X connect 5 0 8 0; #X connect 7 0 2 0; #X connect 8 0 6 0; #X connect 8 0 7 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
You cannot get a zero-size feedback delay in Pd at all, regardless of subpatch ordering or creation order. The subpatch-stuff only is valid for non-feedback connections. The best you can do is do a [block~ 1] or [block~ 8] Sorry, I forgot to mention that I used [block~ 1] objects within the throw and catch modules. I found that the creation order was important though: The patch wouldn't work unless I instantiated the abstraction with 'catch~' in first- I guess because data cannot be 'thrown' to a bus without it existing first... K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
I have had success using throw~ and catch~, as the destination bus can be changed by setting throw~, BUT- throw and catch use a minimum block size of 64. Hm? They don't, unless you do feedbacks, but then everyhting~ in Pd has a delay of one block. How true, I must have overlooked this... Fantastic news Thanks K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
Thanks for this, its cleared things up. Is there any purpose in the $0-delline2 delay line though? K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zero delay feedback, with settable send?
Actually, sorry- I thought I understood this but I've got a problem with this method Considering the patch posted by Georg Holzmann (the same principle as http://crca.ucsd.edu/~msp/techniques/latest/book-html/node121.html)- Surely if the block size is default 64 samples, the delwrite atom will take at least 64 samples to write to the delay line... So the delread (next in sequence) cannot read out the contents of the delay line until AFTER this has happened? I don't understand how a minimum delay of 1 sample can be achieved (although I admit I have made it work in practice!!!) Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Zero delay feedback, with settable send?
Hi everyone Here's my problem: The project I'm working on requires the use of feedback loops, something I am currently implementing by using delread~/write~ in Pd with a 0 length delay. This also adds a fixed minimum delay of the block size, but this can be reduced by using block~. The problem with this- is I cannot set the destination of a delwrite~ dynamically. This is something integral to my project. -I cannot use a message box with 'set x' with a delwrite, it's not supported. I've been using this patch to do tests http://www.zen26398.zen.co.uk/temp/conn4.pd I have had success using throw~ and catch~, as the destination bus can be changed by setting throw~, BUT- throw and catch use a minimum block size of 64 and the resulting delay is too long for my purposes. I'm really stuck. Anyone got any suggestions? I thought about using arrays, they can be dynamically set. It also appears the block size can be set too, but not for tabsend~ (which is the most ideal as it continually writes). I thought that in theory I could write continuously to an array using tabwrite~ and continuously read from it using tabreceive~ or tabplay~, but I can't make it work in practice. Anyone else tried doing something similar? Regards K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] simple Q- co-dependent values
Excellent, works perfectly thanks Kim On 5/5/07, Peter Plessas [EMAIL PROTECTED] wrote: Hi Kim, set is the magic word here: [set 100 | | (numberbox) sets the numberbox to 100 without causing it to output 100. [set $1 makes the value variable. lg, PP Kim Taylor wrote: Hello everyone I have a little question which should be simple but I can't think of how to do it. In Pd, I have two number boxes and I want for them to be ratios of each other. I want it so that If I change one then the value of the other changes accordingly, also vice versa so that changing either of the values affects that of the other- if you see what I mean. How can i implement this without feedback loops and stack overflows? Just hooking up loops crashes Pd, and I understand why this is, but can't think of a way around it. Can anyone help? By the way can you post (and reply) to this list without having to get the threads sent to your email? I don't know how to reply to a specific thread without having the thread in question in my inbox and clicking 'reply' to it. Thanks K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] simple Q- co-dependent values
Hello everyone I have a little question which should be simple but I can't think of how to do it. In Pd, I have two number boxes and I want for them to be ratios of each other. I want it so that If I change one then the value of the other changes accordingly, also vice versa so that changing either of the values affects that of the other- if you see what I mean. How can i implement this without feedback loops and stack overflows? Just hooking up loops crashes Pd, and I understand why this is, but can't think of a way around it. Can anyone help? By the way can you post (and reply) to this list without having to get the threads sent to your email? I don't know how to reply to a specific thread without having the thread in question in my inbox and clicking 'reply' to it. Thanks K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Re: DSP loops
Yeah, you're going to need to need to go with the small blocksize to realise this in vanilla Pd. But a blocksize of one isn't absolutely necessary, you'll probably get away with 8 or 16 for the frequency ranges of typical plucked/hammered strings. Very true... blocksize 2 will give me a range of 22KHz, 4 will give me 11KHz, which might well be more than enough for the ranges of stringed instruments- time to research!! Thanks I hadn't thought of that -K Also, the patch is extremely simple, so I wouldn't worry about the expense too much. Just wrap it in an abstraction/subpatch so that the rest of your patch can run with a standard 64 block. Ok, here's an improvement http://www-users.york.ac.uk/~kt503/PD/kt_PluckedString_23Jan.zip Take care not to get caught out by the creation order gotchya for [s~]-[r~] pairs :) Check the archives on this. As Frank pointed out recently on a similar topic the minimum delay loop time with this is actually zero, so an extra [z] wouldn't hurt. Andy On Tue, 30 Jan 2007 19:24:12 + Kim Taylor [EMAIL PROTECTED] wrote: By the way, Kim, could you tell me what the feedback loop is? (what kinds of operations are you using? is it linear?...etc...) If it's linear, you should be able to replace the feedback loop with an equivalent operation, which circumvents the whole problem. The structure I am implementing is basically a modified model of the structure shown on this page - http://ccrma.stanford.edu/~jos/swgt/Rigidly_Terminated_Ideal_String.html I have this model working (by using a delay with length 0 and blocksize set to 1), if you're interested it's here http://www-users.york.ac.uk/~kt503/PD/kt1-d_DWG-a.zip (unzip to folder, open 1-Ddwg-2g.pd) However I now need to integrate this with other modules on a higher level (this is just a simple component). The idea is that the delay line is bi-directional, and at the terminations they always form loops, so as far as I can see it can't be implemented without it... K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] DSP loops
Hi again all I'm having a bit of trouble putting my program together. I'm trying to implement a series of object blocks that form the synthesis framework, up until now everything's been ok. My problem is that on the top level of the program, I'm trying to connect the blocks together, but the configurations I desire involve feedback and result in error: DSP loop detected (some tilde objects not scheduled) I know send~ and receive~ can be used to overcome this, also throw~ and catch~ if I'm not mistaken. However I can't use these as they result in a fixed length time-delay. Normally this wouldn't matter so much, however as my synthesis technique relies almost fundamentally on very small delays (I'm implementing digital waveguide synthesis) this fixed delay time makes a huge difference. I'm not terribly experienced with Pd, has anyone been in a similar situation and care to share some experience? The only way I can think of overcoming the DSP loop problem is to use a delread~ and delwrite~ to complete the loop, setting the delay time to 0 and setting the level sampling block size to 1. However this seems a very roundabout way of doing it and not ideal, especially for the top level of the program! Cheers Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Re: DSP loops
By the way, Kim, could you tell me what the feedback loop is? (what kinds of operations are you using? is it linear?...etc...) If it's linear, you should be able to replace the feedback loop with an equivalent operation, which circumvents the whole problem. The structure I am implementing is basically a modified model of the structure shown on this page - http://ccrma.stanford.edu/~jos/swgt/Rigidly_Terminated_Ideal_String.html I have this model working (by using a delay with length 0 and blocksize set to 1), if you're interested it's here http://www-users.york.ac.uk/~kt503/PD/kt1-d_DWG-a.zip (unzip to folder, open 1-Ddwg-2g.pd) However I now need to integrate this with other modules on a higher level (this is just a simple component). The idea is that the delay line is bi-directional, and at the terminations they always form loops, so as far as I can see it can't be implemented without it... K ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] minimum delay time for delread~
Hi everyone, I'm new to the list (and pd) so I hope this posts OK. I'm creating a series of patches that rely pretty fundamentally on delays- and I've noticed that the function delread~ seems to have a minimum value of delay time (1.48ms). Values below this point simply trim to 1.48ms. Could I achieve smaller delay times with any other standard functions, or would I have to write custom abstractions to do this? If so, what's the best way of going about it? Writing to tables? Any advice would be really helpful Kim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
