• palaver

    @Michael All the steps are pretty clearly detailed in #6. Which part are you having difficulty with? Have you verified you have python installed on your computer and which version it is? Do you know how to navigate to the folder you created for the project? Are the version-dependent python http-server commands unclear/not working?

    All of step 6 is just to run a little web server on your computer so you can test things out before putting it on your internet-facing web server. You could just as easily upload all of the files to your remote server and test it if you don't mind others being able to see it.

    posted in libpd / webpd read more
  • palaver

    Hmmm, a quick browse of the supported objects notes that bangs [bng], sliders [vsl]/[hsl], toggles [tgl], and radios [hradio]/[vradio] all work within the patch.
    No additional HTML/Javascript knowledge necessary. Is that what you were looking for? Otherwise, the readme notes the use of JS to send messages to your patches from the web page. In this case you'll have to take a crash course on JS/HTML to get much done. If you do end up going there, there are some pretty cool JS knobs and other control widgets available.

    posted in libpd / webpd read more
  • palaver

    "... the challenge is being able to differentiate a silent connection from no connection"

    Good point, and exactly the thing that made me disfavor signal detection. I may well want to insert something that actually attenuates the signal, say like a volume pedal. By convention, I guess I could use an offset like you describe. I think I'd prefer a toggle at that point, considering the extra work adding the offsets would entail throughout my patches, but it is interesting to think about in any event. Thanks for tossing that idea out there.

    posted in technical issues read more
  • palaver

    Thanks David. The only reason I considered signal detection was to avoid using a toggle. This is an exercise in pure laziness and interface design. Were there a method for detecting not signal, but a connection to an inlet, I would be where I want to be. Not strictly necessary by any means, just a convenience.

    posted in technical issues read more
  • palaver

    I've been wondering how to emulate the normally connected effect send/return pair that is found in most pro mixing consoles in a patch that would function something like the diagram below:

    Insert.jpg

    The idea being that the signal path proceeds straight from inlet to outlet unless something is inserted to redirect the signal through another patch then back to the insert point and on to the outlet. This would seem to be a straight-forward task if it were possible to detect whether or not a connection exists to a specific inlet or outlet and then reroute the signal accordingly. Is this possible in Pd Vanilla? I've thought of a hack to reroute the original signal based on the presence of a signal at the return, but would prefer to base it on whether or not the connection exists instead.

    Basically, I just want to expose interesting insert points in some patches for quick and easy application of discreet effects or processing without having to dig into their guts every time I want to add some reverb, delay, vibrato, or whatever.

    Thanks,
    P

    posted in technical issues read more
  • palaver

    The update did the trick. I can now use the mover more predictably, except of course it is difficult to know when you've reached the exact size to fit. More importantly, 'fit' gets the size right. I find that I have to move the content up four ticks every time to get the whole object with the GOP window though, but that's a small price to pay for an otherwise perfect fit. Also, good move on the 'normal speed' button in the content properties. Not sure if that's new or not, but I was searching for a way to get the speed correct without too much effort when setting up.

    Thanks again for sharing your work. I'm doing some weird out-of-sync sample playback experimentation, and Context is giving me a lot of flexibility.

    posted in patch~ read more
  • palaver

    Count me as interested in this thread too, only I won't have much to contribute as I am absolutely new to actually designing reverb patches. Thanks for sharing your patches and links. I've always had a kind of background fascination with reverb ever since I learned audio production techniques in the 1990's. Back then, I couldn't get enough Lexicon 'math' in my mixes, while of course it was a special treat to have access to a beautiful room that could be mic'd up and used as an old-school reverb chamber.

    posted in patch~ read more
  • palaver

    Thanks for sharing your sequencer! I look forward to getting familiar with it. One question so far: How do I get samples that have been loaded in content objects to fit the entire overlay area? The manual suggests using the 'fit' command, but when I send it to the content command message inlet, I get 'command not recognized: fit' in the Pd console. I also tried using a mover object and was able to resize one content object after quite a bit of fussing, but I haven't been able to repeat the feat with others.

    Thanks,
    p

    posted in patch~ read more
  • palaver

    [1 2 3 4(
    |
    [list length]
    |
    [print]
    

    That will give you the list length, but be careful, if you supply [1, 2, 3( as the source message above, the output will be three 1's, as the comma actually delimits multiple messages from within one message object.

    Hope that helps.

    posted in technical issues read more
  • palaver

    @kempkeith, The SS2 is great! It really shines in the MIDI realm, but offers a decent amount of functionality with OSC as well, as long (as you're willing to keep it "hosted" within an app running on your desktop). The customization on offer is mind-blowing and pretty easy to understand after poking around the software for an hour or two. Funny thing is I started out using OSC and hosting quite a bit of my logic right on the SS2, but soon realized if I switched to MIDI, I could manage all the communication from a Pd abstraction that updates the LEDs and display as the state of my patch changes. Right now I use it in one of its most basic configurations sending CC messages in response to button down/up events and receiving LED/display updates, and I couldn't be happier. The physical construction seems pretty bullet-proof so far - slightly flexible, but resilient.

    posted in I/O hardware diyread more
  • palaver

    Hey all, I know this is an old thread, but considering the difficulty I had in locating a good footswitch/trigger, I thought I'd add to the recommendations here in hopes that someone else may find it useful. What I've been using for the last few months is the Keith McMillen Instruments SoftStep 2. It consists of TEN buttons (actually d-pads that can send x/y-axis pressure and loads of other data, if you take the time to program it) plus one giant d-pad/internal patch browser that can also be customized. It communicates via MIDI note, CC messages, or OSC, and also accepts commands to activate LED lights and a four-character display to give the user some feedback from Pd. While it has a hefty price-tag, it is indispensable to my current efforts at designing a multi-loop phrase looper inspired by the Echoplex Digital Pro in Pd, and I have about 20 ideas of how to use it in the future with Pd and other hardware/software.

    Cheers,
    p

    posted in I/O hardware diyread more
Internal error.

Oops! Looks like something went wrong!