• LiamG

    Well that's a pain. I'm guessing if I place them directly, I won't be able to read the elements' positions using [get], right?

    posted in technical issues read more
  • LiamG

    @ingox This is strange--in my patch, I'm not getting any of those useful "change" messages coming out of the [struct] objects, and I can't work out why. Is it something to do with the "float c" argument? I tried adding this and it still didn't work, though I might be getting the syntax wrong.

    Here is my container for the element:

    ds1.png

    and for the array:

    ds2.png

    Out of either of the [struct] objects, the only message I get is "click (pointer) 0". Any ideas?

    posted in technical issues read more
  • LiamG

    @weightless imagine you were reading a sentence but that each time you read a word you had to "pick up and move" every remaining word in the rest of the sentence. That's what the traditional [list-split] -- [list-append] approaches to iteration do!

    ( [list-split] doesn't actually have to copy every single word in the rest of the sentence, but it's still a heavy load).

    posted in abstract~ read more
  • LiamG

    Ah, I hadn't thought of unpacking the [struct] message like that! Thanks @ingox, the next version of my [sketch] project is going to be much better because of this!

    posted in technical issues read more
  • LiamG

    At last! It's shocking that Vanilla hasn't had a solution to this for so long.

    posted in abstract~ read more
  • LiamG

    Here's my latest challenge with data structures. I have a 2-dimensional graph holding a series of data-structure points, which I can drag around the canvas. Now I'd like to be able to hold down the shift key (or something) and drag the points only in the x- or y-dimension. Is this possible? The best I can think of is to save the coordinates and then use them to reset the x- or y- data when the shift key is set, but this would be a bit of a hassle. Is there some provision within data structures to be able to do this?

    Counting on you @Balwyn and @ingox!

    posted in technical issues read more
  • LiamG

    I'm afraid that Andy hasn't been seen around these parts for quite some time (his last post was 8 years ago and this one is 12 years old!) His website has been down for quite a while too, though you can still access it via archive.org.

    You might also be interested in this awesome book which he wrote.

    posted in patch~ read more
  • LiamG

    [bang~] is a bit heavy for this kind of thing. If it were me, I'd use a metro and save some CPU.

    posted in technical issues read more
  • LiamG

    It's working fine with inlets~ for me. The following patch gives a 1 if the inlet~ is connected to anything and a 0 otherwise.

    connections.png

    If I wanted to query the second inlet, the correct message would be "inlet 1".

    posted in technical issues read more
  • LiamG

    I've made some updates to [sketch]. A couple of bug fixes, plus a nifty new feature: you can now shift a point in only the x- or y- axis, by holding down the arrow keys. This makes it easy to fine-tune envelopes and such.

    If you haven't done so already, check out the examples inside "custom formulas" in the help patch. The latter example shows how to draw an array inside an array, which is pretty crazy!

    The download link is still the same:

    https://github.com/LGoodacre/context-sequencer

    posted in patch~ read more
  • LiamG

    If you don't mind using externals. you can use [iemguts/canvasconnections] to detect whether anything is connected to an inlet.

    posted in technical issues read more
  • LiamG

    Just to be clear, x^2 is a quadratic, not an exponential function. 2^x is exponential. This won't change the method of populating the array though.

    posted in technical issues read more
  • LiamG

    Oh wow, this does sound good. Thanks for digging it up!

    posted in extra~ read more
  • LiamG

    There has been a lot of discussion about this on the list. A recent TCL update has changed the font sizing, and the regular startup flags don't help. There may be a solution to this problem in 0.48.1, but for now, we're stuck with it.

    posted in technical issues read more
  • LiamG

    I've spent a lot of time being frustrated with this kind of thing also. If you're not savvy at compiling software, it can be very hard to keep up to date with the latest version of PD.

    I asked once about why the repositories aren't up to date, and it turns out that this is out of our hands. Ubuntu only accepts updates to repositories every so often, in the interest of stability (can't remember the details). So if you want the latest version of Vanilla for Ubuntu, you're going to have to download the source files (top link in the page you shared) and compile it yourself.

    Luckily, this has gotten MUCH easier in 0.48 with the updated readme file. I was able to do it without any difficulties this time (and I'm not an expert at these things). Just follow the instructions carefully, and report back if you have any difficulties.

    posted in technical issues read more
  • LiamG

    Also try [svf~] from Cyclone. This is a low-pass, high-pass, band-pass and all-pass filter all in one, with resonance and cutoff both controllable in signal and control level.

    There are also a lot of filters available in the iemlib library.

    posted in technical issues read more
  • LiamG

    You might have better luck contacting the university itself. @freakydna doesn't seem to have posted at all since this.

    posted in news read more
  • LiamG

    Option 1 (simple): Use [send] and [receive] objects to communicate across patches. [send here] will be received by [receive here] in any patch, and just like a regular cable, you can use it to send anything. Use [send~] and [receive~] for audio.

    Option 2 (advanced): Create abstractions. An abstractions is a PD patch encapsulated as a PD object. This sounds complicated, but it's actually quite simple: Just save your patch in the home folder you're working in, then open a new patch and create an object with the same name. For instance, if your saved patch is called "drums.pd", then create an object [drums]. To communicate with the abstraction, you'll need to use [inlet] and [outlet] objects. These will create the familiar PD inlets and outlets, which you can connect to. Use [inlet~] and [outlet~] for audio.

    posted in technical issues read more
  • LiamG

    Wish I could come to this! I so want to build this system.

    posted in news read more
  • LiamG

    Thanks for chiming in @jancsika. You confirmed what I thought about the "stack overflow" counter. Pondering the issue more, I think what I am trying to get at is the difference between memory overflows and CPU overflows. These seem like very different things, although they are covered by the same error message. I'm going to elaborate my question, because I suspect that you do know the answer, if only I can communicate clearly.

    My intuition tells me that the first example I posted uses a lot more memory than the second, precisely because it has to remember the numbers 0-98 before it gets to print anything. If the process continued for long enough, it would lead to a memory overflow, ie. the stack would be required to store more numbers than its capacity allows. This is what the "stack overflow" counter is there to protect against.

    In the second example, however, the memory overflow doesn't seem to enter the picture. The number is forwarded to the print object and "forgotten" before it is sent back to the top. So if the second example were run without [moses] or any other safety limit, it would not eat up the memory. It would, of course, lead to a CPU overflow, since the process would never terminate, and the computer would still crash if the "stack overflow" counter failed to intervene. But it would crash for a very different reason than the first example, ie. because of a CPU overflow, not a memory overflow.

    Does my reasoning here seem correct? Is there anything I've overlooked?

    I'll now give some context to my question, because you're probably wondering why I care so much about these details. The context is Context, the library that I'm building. Context uses a lot of recursive functions similar to the second example that I posted, and I'm trying to decide whether or not it's worth rebuilding them using [until]. This would be a lot of work, but there are two reasons why it might be worth doing: 1: Because it would make Context more efficient, and 2: Because recursion will lead to unwanted error messages, as @ingox pointed out.

    I am currently much more interested in 1 than in 2. For whatever reason, unwanted error messages have not been a problem for me so far (perhaps because I haven't reached the limit). As for efficiency, the standard answer seems to be that it doesn't make an appreciable difference on modern computers, but in fact I am finding reasons to care about it. Context has a heavy loading procedure, involving several recursive algorithms of the type I've outlined in the second example. Load time is something I care about because it can lead to audio dropouts, hence I am trying to decide whether or not I need to replace my recursive systems with iterative [until] based systems. I ran a simple test* for one such system and found that the recursive system actually seemed to run faster than the iterative counterpart, contrary to what I had expected. This makes me inclined to stick with recursion, but I'd like to know if there is anything that I have failed to consider.

    *I can provide more details about this test you like, but I'm worried that if I do so now it would lead to a memory to overflow!

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!