• oid

    @seb-harmonik.ar For fixed number of i/o it seems like just sticking cascaded [select]s in an abstraction would make more sense, or am I missing something?

    posted in technical issues read more
  • oid

    @whale-av Seems to be one of those old forum posts where the attachment links do not work, did they work for you or did you just link the thread? Can't seem to find this one anywhere else, curious as to he went about the task, guessing he tailored it to OPs needs to keep things simple which is generally a better solution unless you do it often enough that you actually require a generic solution.

    posted in technical issues read more
  • oid

    @gentleclockdivider We can do this as an abstraction with dynamic patching, this is one of those areas where it is a little awkward but nothing too terrible. You can send a list longer than the creation arguments to the cold inlet and it will still remove those numbers, you just will not get an outlet with a bang for any numbers which extend beyond the creation list's arguments. Could be done simpler if we moved the outlets outside of the abstractions and just gave it two outlets, but it is not so bad. I suspect this can be simplified, feel like I am over-complicating things but am failing to see how. Requires iemguts which I have no idea if works with plugdata but I am only using [initbang] from iemguts and there could be another [initbang] in some other lib which plugdata supports. There is a limit to the number of outlets you can get before you will have an issue with the rightmost outlet no longer being rightmost, should be high enough for most uses though. I got lazy here and just place the [r] and [outlet] manually so the created outlets for the bangs could end up further right in the abstraction. Perhaps I will fix that later.
    sels.pd
    Untitled.png
    Sort of patch which really makes me wish we had some sort of math expansion in messages.

    posted in technical issues read more
  • oid

    @seb-harmonik.ar That explains why it does not work for me. Back when I tried it https://github.com/pure-data/pure-data/issues/846 had been closed at the post explicitly stating that pulseaudio was supported through portaudio.

    posted in technical issues read more
  • oid

    @mario60 said:

    How do I try?

    As far as I know you just select portaudio in the media menu and it should just work, but as I said, it never has worked for me and I never really bothered to explore why since I am ok with Jack and need it for other applications anyways.

    posted in technical issues read more
  • oid

    @mario60 PulseAudio is hogging alsa. Supposedly you can use pd with pulse audio through the portaudio backend but it has never worked for me. You have a few other options as well, you can install jack recompile pd with jack support, this requires you to run pulse into jack, or jack into pulse, or suspend pulse when you start jack. Or you can suspend pulse and use alsa direct. Portaudio->PulseAudio can be troublesome with audio, Pulse has a fair amount of latency so if you want to process live sound it generally is not a viable option, but if you just want to patch together synths in pd than it should be fine.

    Jack is the most reliable and the frontends for jack have provisions to handle the pulse stuff for you, but you will probably need to do some setup the first time around on a system like Fedora which does not seem all that popular in the audio community. Initial setup can be a pain but once it is going you just start jack and that is it. Suspending pulse manually and using alsa works well but there can be surprises when restarting pulse, and they can be a trick to sort out.

    posted in technical issues read more
  • oid

    @ddw_music Well, it sort of is right since the [mod 5] before it means the [select 0 5] will never see a 5 so the polyrhythm will play properly in its entirety. The reset was a last minute addition and I clearly did not think it through all of the way. Fixed. Thanks for pointing that out.

    posted in technical issues read more
  • oid

    @gentleclockdivider Oh, figured out the confusion regarding division/multiplication, we were not talking about the bangs themselves but the math, at least I was, perhaps David had something else in mind? Anyways, this is the sort of setup we were discussing, believe you figured it out but for those following along.
    Untitled.png

    posted in technical issues read more
  • oid

    @gentleclockdivider You missed my edit, generally wise to wait a few minutes before responding to me, I almost always have an edit, often many edits. I think one of us is missing something here. Why would you want to multiply them when you can just speed up the metro and make everything a division of that? Just as an exercise? Best I can think of for multiplication are the two options I outlined above, cheat with a delay or time the bangs, both have issues which are removed by just using a faster clock and dividing.

    posted in technical issues read more
  • oid

    @gentleclockdivider Division by 2 is the same as multiplication by 0.5 :)

    Edit: or are you asking how to make it work with a slow clock and not just confusing yourself by over complicating things? As someone who constantly confuses themselves by over complicating things, I can not tell when others are doing it or just asking a question?

    Properly timed multiplication would be by cheating with a delay, I think, I can not think of any other reliable way. But you could certainly measure the time between two bangs to output one between, but things would get hairy rather easily.

    posted in technical issues read more
  • oid

    @whale-av I was surprised you did not mention it, fairly certain you are the one who pointed this out to me in the first place. I believe I found that division works better despite computers being more efficient with multiplication, I have a vague memory of discovering that there is something regarding the PD gui, when it starts lagging there is less chance of the metronome lagging/audio lagging when dividing. But that was a very gui intensive patch and is only a vague memory. I think all that matters is being aware that switching to division or multiplication may solve issues with lagging for those rare occurrences that it is actually an issue, the rest of the time we can just go with what is easiest/most readable/most intuitive and enjoy the ignorance.

    posted in technical issues read more
  • oid

    @gentleclockdivider A simple way to avoid this is just to reduce this down to a single metro banging a counter which you use to derive your timing information for everything through basic math and the use of [select] to get your bangs.

    posted in technical issues read more
  • oid

    @vfsonore I don't think iemguts would work with Trill anyways but Trill looks to have pressure sensitivity, so all you need to do is replace [receivecanvase] and [route mouseup] with some logic to read zero pressure, so pressure data into a [change] and than a [sel 0] should do it. You can dump the [set $1( message completely and replace the slider with your position data.

    Edit: and you would probably want to read the initial position value as zero and subtract that from all subsequent position data so you do not have to worry about hitting dead center to avoid a sudden jump.

    posted in technical issues read more
  • oid

    @vfsonore How about this? Uses [iemguts/receivecanvas] to detect mouseup and reset the slider.
    bender.pd
    Untitled.png

    Edit: Had a spare moment to fix it afterall, think I sorted it all out.

    posted in technical issues read more
  • oid

    @Load074 Since it takes so long you may want to just log all those prints externally. You can use the pdreceive command line application to send the data out of pd with the [netsend] object. So instead of connecting thing to various [print] objects you prepend a descriptive label to the data and then send that into [netsend]. Run pdreceive [port number] >> [logfile name] then send the [connect <port number>( to your [netsend] object in pd, and start the patch, everything gets send there. Then you can use a text editor or the standard command line tools to examine the text file after the crash, just control-c to kill pdreceive after pd freezes. Useful tools too examine the log will be things like tail and grep, tail -50 [logfile] will give you the last 50 lines of the log, tail -50 [logfile] | grep [label] will give you the last 50 occurances of all entries for [label]. Should make it much easier to decode the problem. The [trace] object could also be of use here. And there are a great number of other useful tools on the command line, any of the tools used for working with text files like cut and sort and the shells own scripting language, any good guide for your shell should help you here if you do not have much experience with shell scripting and the command line apps.

    And time is relative, no need to wait an hour, speed up your control objects, if everything is under control of a master [metro] make it run 10 times faster and you will get your result in a tenth of the time. If you are logging it all to a file you do not need things to run slow enough that you can read them in the log window.

    posted in technical issues read more
  • oid

    @lacuna said:

    Wish there was a shortcut to open objects-help.

    That is simple to add through tcl, this plugin shows how

    posted in technical issues read more
  • oid

    @whale-av said:

    I have seen it done many times.
    Or if an example can be found on the forum it can be analysed.

    Those are probably just resizing the object with the mouse? I do not think there is a character you could use that will not cause an error with a [trigger] since it is rather picky about its arguments.

    posted in technical issues read more
  • oid

    @timothyschoen One of the primary reasons I have avoided looking into alternate pd interfaces is that wire types often do not translate well, a nice neat patch in pd can be difficult to follow in PurrData with its wiggly cables and vice versa. Any chance for a simple way to switch on the fly between pd/purrdata/plugdata wire types? No idea if JUCE provides alternate wire types.

    posted in news read more
  • oid

    @ddw

    Possibly somebody complained that they were getting cables when they wanted to move the object.

    I follow pd's progress on github and have never seen such a complaint, so I do not think that is it, but there could be a good number of us who just assumed the problem was with ourselves and not pd.

    posted in technical issues read more
  • oid

    @ddw_music Control+ will make them twice as large...

    I started having issues with this somewhere during 0.52 but never did before, could be I am getting old and/or lazy but it could be something accidentally got changed recently. Maybe the mailing list where the devs are would be a good place to ask? I assumed it was me.

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!