• NoDSP

    I can say that I have had some very similar graphical problems when compiling on a Debian Sid install that was also missing fonts and possibly other components as well. No such problems with the same packages on older platforms such as Ubuntu 14 or Debian Squeeze.

    posted in technical issues read more
  • NoDSP

    Thank You!

    I've make a whole console of editors of synths I had on hand but had to hold off on the Nano because the Alesis power supply gave out. I'll let you know how it works as soon as I score a new P.S.

    posted in patch~ read more
  • NoDSP

    Just a small note: You can simplify that test patch (or any other use of the midi out objects) by replacing the triggers and multiple message boxes with three element list messages connected to the first input of the midi output object.

    posted in technical issues read more
  • NoDSP

    @jancsika said:

    Yes.

    Ok, Thanks.

    posted in news read more
  • NoDSP

    @jancsika said:

    What were the problems?

    Well, I'm not sure how relevant it is now as that was back when I first started experimenting with GOP abstracts and I can't even remember which version or versions of Pd I was using at the time. Basically it was an intermittent problem of the top-pasted objects disappearing behind the GOP under certain conditions, such as when the patch or window was closed and opened again, or when the GOP was opened. Even without those issues it just seemed like a klutzy inelegant way of implementing things so at the time I just decided to move on with a different approach.

    posted in news read more
  • NoDSP

    @Monetus Ah yes, thank you. I've actually got a large number of waveforms already loaded into multiple banks of array objects that I could put to use this way. I still have to work out those output range scaling issues, though.

    posted in technical issues read more
  • NoDSP

    @jancsika Also, I just noticed you added this ticket

    https://git.purrdata.net/jwilkes/purr-data/issues/272

    That would address the problem of the label adding to the object's size, but would the label still appear both inside the GOP (when opened) and outside the GOP border (on the parent canvas), the same way as it does in Vanilla?

    posted in news read more
  • NoDSP

    @jancsika I don't know if you know the answer to this question, but just out of curiosity, why was the label behaviour changed to begin with? Was it problematic to work it into the post-vanilla interfaces? Was the change even intentional or was it just implemented that way because it was assumed vanilla worked that way? Would it affect compatibility with L2ork patches to just switch the whole thing back to the vanilla implementation?

    The reason I ask is because when I think about it, I can understand the change to the inlet/outlet spacing, but Miller's original label behaviour just seems to make more sense. Take example 2. If I did that in L2ork and wanted to use the internal label function, I would have to extend the GOP border all the way to the end of the label, leaving a ton of dead space. I don't have that space as there are more controls next to it in the patch that I don't want inside the glide GOP and don't really belong there as they have nothing to do with the glide GOP's internal logic (deleted in that example for clarity -- there's quite a lot of it) . I could try pasting them on top of the dead space in the GOP, but I've had problems doing that kind of thing in the past so I generally avoid it. As I mentioned above the other option is to use a labelled canvas, but it seems like this is an unnecessary limitation of the internal labelling function.

    posted in news read more
  • NoDSP

    @jancsika Yes, this is what I was trying to get at with the comments as I figured that out when I put the file together. It's basically the same problem with the first three examples. Vanilla doesn't handle labels the same way -- you can place the label anywhere inside or outside the GOP border and it works just as if you had placed the GUI object directly on the canvas without the GOP abstraction. Vanilla doesn't see it as part of the object.

    It still leaves me (and anyone else with legacy patches set up the like this) with the same problem -- I'd have to redo all of that (I've got lots of those) and then have to replace the object labels with small labelled canvases outside the GOPs just to make the patch compatible.

    posted in news read more
  • NoDSP

    @jancsika I actually haven't been able to test w/extended recently but I remember running into similar problems.

    Yes I figured that was an auto spacing issue with #4 but as vanilla lets me do it with no "collisions" that's the way it was set up originally as I was dealing with some very dense, tightly spaced GUI panels. Can the -legacy flag be made to disable this?

    posted in news read more

Internal error.

Oops! Looks like something went wrong!