Hi there,
I would like to share a project I am working on for a while which might interest anyone who like making physically interactive or reactive installations.
It’s a plug-and-play sensing platform for creative and audiovisual applications, with MIDI, OSC, wireless capabilities and a convenient web interface.
You can turn movement, touch, distance, or other sensors into wireless controllers in seconds.

I developed this project to ease the connection of sensors to audiovisual and music software. After doing that with arduino for years, but encountering so many limitations and struggles, I decided to make and share a much easier, convenient and robust solution for all: the whole project will be open sourced.

The project is called “Pipo Interfaces”. It is still in the making and will be launched as a pre-order campaign on Crowd Supply (a funding platform for open source electronics).
If you are interested, check out the pre-launch page and subscribe to the project updates !

https://www.crowdsupply.com/pipo-interfaces/pipo

You can also check the Insta @pipo_interfaces
Any feedback or questions welcome !

@jameslo said:

For instance, I just learned that the Mac version of REAPER runs AUs, so I tested in REAPER and there were no issues. So to me it's a tossup whether I should report it to the QLab group or the plugdata issue list.

Reaper gives some insight, because its file format is text.

I created a Reaper project with a single track, and two effects: plugdata and ReaEQ. I saved two versions of this product, with slightly different plugdata patch contents. Then I opened both files in Emacs and did ediff-buffers on them.

The main difference is that a whole long string of binary-encoded stuff (not human readable) changed... plugdata appears as:

      <VST "VST3i: plugdata (plugdata) (32ch)" plugdata.vst3 0 "" 1821045374{ABCDEF019182FAEB506C44745064496E} ""

... a ton of encoded stuff... like 560 lines of it...

>

Since the encoded stuff changed, it means that plugdata renders the patch into the VST preset data. (Good point about this is that a DAW project using plugdata doesn't have to ship with a pd patch file.)

I guess then, for whatever reason, QLab and Audacity are not handling this, while Reaper does. One plausible guess might be that QLab and Audacity have a limit on the size of a plug-in's settings. Plugdata really spits out a lot. The ReaEQ settings are fully represented in 7-8 lines; plugdata, for a minimally simple adc~ --> dac~ patch, needs over 550. It wouldn't surprise me if some audio software assumed "nobody's going to make a plug-in that big."

Hm, here's a thought -- Cardinal synth (VCV Rack fork) should also save patches into plug-in settings, which could get arbitrarily large. Maybe try that in QLab, for differential testing. If they both fail, you would have more ammunition to go back to QLab. If QLab handles a large Cardinal patch but fails on plugdata, that seems more like a plugdata bug.

Audacity is open-source, so it may be possible to find a limit in the code.

Could be something else too (maybe plugdata's settings use some data types that certain software isn't prepared for). Or it could be too many parameters. Plugdata publishes 512 free parameters, plus 128*16 MIDI CCs, plus a few other odds and ends. Pretty sure even Vital isn't that big.

(I'm also certain that someone on the QLab group is going to respond "plugWHAT?!!!" )

Yeah, tech support finger-pointing. When I worked in tech support, I saw that a lot of questions that really should have gone to partner companies ended up coming to us, because we were the smaller kid on the playground.

hjh

@ddw_music said:

[...] I had just assumed 4-point interpolation would be cubic.

... which is correct! both are cubic, but with different curves (and the Pd version might be slightly more efficient):

Pd's [tabread4~]:

actual code:

cminusb = c - b;
*out++ = b + frac * (
    cminusb - one_over_six * ((t_sample)1.0 - frac) * (
        (d - a - (t_sample)3.0 * cminusb) * frac +
        (d + a * (t_sample)2.0 - b * (t_sample)3.0)
    )
);

[tabread4c~]:

actual code:

a1 = 0.5f * (c - a);
a2 = a - 2.5 * b + 2.f * c - 0.5f * d;
a3 = 0.5f * (d - a) + 1.5f * (b - c);

*out++ =  ((a3 * frac + a2) * frac + a1) * frac + b; 

@Aliam.Sigsaly the maintainer of pdlua is Albert Gräf. The way open source software works is that one person can use the code from other projects (provided the licenses are compatible). This is called a 'fork' and it doesn't imply that the original project is being 'taken over' or 'annexed' by the fork.

Afaik there are feature request github and discord forums/channels for plug data if you want to discuss the direction of the project (though I suppose this could also be an appropriate venue).

Imo your expectations for an announcement on arbitrary channels for a certain library version not being supported anymore are slightly unreasonable.. I would say that if you want to be informed of plug data or development about a certain version of ophelia there are places to follow in order to do so.

I also don't think it's productive to talk about how superior m4L is unless you're making specific feature suggestions for the project you want to use in a productive and collaborative way.

edit: also, a great thing about open source is that if you don't like the direction of a project you are free to make your own fork and add or remove whatever aspects you wish. The maintainers have a right to include or omit features and library for whatever reason though you are of course free to make criticisms or suggestions (though I have to say your tone did come across as somewhat entitled, rather than collaborative.. for instance you could enquire why something might not be maintained anymore before catastrophizing). But if you want a certain feature without doing the work to implement it that can come across as expecting free labor or agreement on aesthetics.

edit2: personally I disagree with alexandre's "everything in 1 lib" philosophy for else (personally I like using many different established libraries that already have equivalent objects) but he does work hard on it and those aspects have driven its adoption in plug data and many other projects. Also he probably (would have been) open to improvements for it in general if you considered them to be lacking and had made pull requests to improve it or at least given suggestions or feature requests instead of/before complaining..

@cfry The Mrpeach library, or the IEM library update has some basic HTTP objects too.
But I am not sure that it is the HTTP protocol that you want to use.
Looking at the first sentence on that page I think you could use midi..... https://github.com/search?q=repo%3Aikaros-project%2Fikaros+midi&type=commits
or better still a socket using [netsend] as you first suggested.... https://github.com/search?q=repo%3Aikaros-project%2Fikaros+socket&type=commits
maybe specifically "Adding basic modules for socket communication"

The project has been running for a long time.... so there is a lot to read...!
Can a socket module use the same message strings as the web interface?
Probably.
David.

@ddw_music said:

For iOS: https://support.apple.com/en-gb/guide/iphone/iph45447ca6/ios

Connect a Mac or PC to your Personal Hotspot
You can use Wi-Fi, a USB cable, or Bluetooth to connect a Mac or PC to your Personal Hotspot. Do one of the following:
...
Use USB: Connect iPhone and your computer with a cable. If you receive an alert that says Trust this Computer?, tap Trust. In your computer’s network preferences, choose iPhone, then configure the network settings.
...
After that, the Mac should have an IP address that directly connected to the mobile, through the cable. There's no reason at this point TouchOSC would be prevented from sending and receiving OSC messages (while allowing MIDI...? that doesn't make any sense).

Hmm. Thing is, I'm using a fully Airplane Mode iPad with no Wi-Fi, Bluetooth, Cellular Data connectivity. I'm only using a USB-cable to connect between macOS and iPadOS with TouchOSC - so I'm not 100% how Personal Hotspot -specific IP addresses will assist.
overall it seems like there just might not be a netless-USB-tether way of identifying what the iPad's IP address is. all the stuff i see, is about using the iPad as a personal hotspot over usb-cable, and therefore having an IP address to connect PD onto for OSC back'n'forth communication.

HI,

a newbie, I am trying to install and use Pd 0.53.0 on a Fedora 35 machine.
I think I installed (from source) fine, but I do not get any sound.
I am not sure what I am supposed to check and do.

Some info on my install below.
Thanks for your help.

Below, I doubt line audio APIs: PortAudio ALSA OSS is how it should be, but I am not sure how to fix.

pd 0.53.0 is now configured 
Platform:             Linux
Debug build:          no
Universal build:      no
Localizations:        yes
Source directory:     .
Installation prefix:  /usr/local

Compiler:             gcc
CPPFLAGS:             -DNDEBUG  
CFLAGS:               -ffast-math -fno-finite-math-only -funroll-loops -fomit-frame-pointer -O3  -g -O2
LDFLAGS:               
INCLUDES:             
LIBS:                 -lpthread -ldl 

External extension:   pd_linux
External CFLAGS:      -fPIC
External LDFLAGS:     -Wl,--export-dynamic -fPIC

fftw:                 no
wish(tcl/tk):         wish
audio APIs:           PortAudio ALSA OSS 
midi APIs:            ALSA OSS 
libpd:                no 

 
$ ./pd -listdev
audio input devices:
0. USB Device 0x46d:0x825 (hardware)
1. USB Device 0x46d:0x825 (plug-in)
2. HDA Intel PCH (hardware)
3. HDA Intel PCH (plug-in)
4. HDA NVidia (hardware)
5. HDA NVidia (plug-in)
6. Trust PC Headset (hardware)
7. Trust PC Headset (plug-in)
audio output devices:
0. USB Device 0x46d:0x825 (hardware)
1. USB Device 0x46d:0x825 (plug-in)
2. HDA Intel PCH (hardware)
3. HDA Intel PCH (plug-in)
4. HDA NVidia (hardware)
5. HDA NVidia (plug-in)
6. Trust PC Headset (hardware)
7. Trust PC Headset (plug-in)
API number 1

MIDI input devices:
1. ALSA MIDI device #1
MIDI output devices:
1. ALSA MIDI device #1
priority 94 scheduling failed.```

If I try to set to something different from HDA Intel, I get
ALSA input error (snd_pcm_open): Device or resource busy
ALSA output error (snd_pcm_open): No such file or directory
`

Howdy all,

I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.

I'm just writing for myself and don't speak for Miller or anyone else.

Mac looks good

The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.

There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."

In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.

This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.

Nope. See above.

It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.

Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.

tkpath exists, why not use it?

Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.

And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.

It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.

Why aren't the fonts all the same yet?!

I also despise how linux/windows has 'bold' for default

I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.

Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others?

And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.

Why don't we add abz, 123 to Pd? xyzzy already has it?!

What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.

Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

Yes, this is correct, but first we have to keep the damn thing working at all. I think most people agree with you, including me when I was teaching with Pd.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.

This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).

A couple of points:

1. Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.

2. As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.

I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work.

A way forward: libpd?

I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."

For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."

So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).

Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.

Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.

Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...

Discouraging Initiative?!

But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.

We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.

At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.

This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.

That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.

Out

Ok, that was long and rambly and it's way past my bed time.

Good night all.

Just Another (Drum) Sequencer...SortOf, codename: Virgo

virgo.zip

REQUIRES: zexy, moonlib, tof (as of Pd 0.50.2, all of which are in deken) and hcs (which comes by default with Pd 0.50.2 and is in deken (for extended))

Special Features

• Unique playhead per row; each with their own metro (beat)
• Up to 8 Volume states-per-beat (by clicking multiple times on the bang; where an rms=1 is divide among the states (2 states:0=rms=0(black), 1=rms=1(red); 3 states:rms=[0|0.5|1])
• Design approach: using creation arguments to alias abstractions, so subsequently they are referred to by their creation arguments, ex. in [KITS sample] sample is referred to as [$1]; which is how they are listed below)

(notes: what I learned experimenting with this design approach, I will share as a separate post. Currently, it does not include cut-copy-paste (of regions of the pattern)). I good way to start trying it out is clicking the "R" to get a random kit and a random pattern).

virgo:[virgo/PROJECT KITS PATTERNS]

• PROJECT[KITS PATTERNS]
  • $1:[KITS sample]
    • GUI
      • K: openpanel to load a previously saved *.txt (text object) kit of samples; on loadbang the default.txt kit is loaded
      • S: save the current set of samples to the most recently opened *.txt (kit) preset
      • SA: saveas a *.txt of the current set of samples
      • D: foldererpanel a sample directory to load the first (alphabetically) 16 samples into the 16 slots
      • RD: load a random kit from the [text samples] object where the samples where previously loaded via the "SAMPLES" bang on the right
      • U: undo; return to the previously opened or saved *.txt kit, so not the previously randomized
      • MASTER: master gain
      • (recorder~: of the total audio~ out)
        • record
        • ||: pause; either recording or play;
        • play: output is combined with the sequencer output just before MASTER out to [dac~]
      • SAMPLES: folderpanel to load a (recursive) directory of samples for generating random kits
    • ABSTRACTIONS
      • $1: sample
        • bang: openpanel to locate and load a sample for a track
        • canvas: filename of the opened sample; filenames are indexed in alignment with track indices in the PATTERNS section
  • $2:[PATTERNS row]
    • GUI
      • P: openpanel to load a previously saved *.txt (pattern) preset file; on loadbang the default.txt pattern is loaded; the preset file includes the beat, pattern, and effect settings for the row
      • S: save the current pattern to the most recently opened pattern .txt
      • SA: save as (self-explanatory)
      • states: the number of possible states [2..8] of each beat;
      • %: weight; chance of a beat being randomized; not chance of what it will result in; ex. 100% implies all beats are randomized ; random beats result in a value)gain) between 1 and states-1
      • PLAY(reset): play the pattern from "start" or on stop reset all playheads to start
      • start: which beat to start the playheads on
      • length: how many beats to play [+/-32]; if negative the playheads will play in reverse/from right to left
      • bpm: beats-per-minute
      • rate: to change the rate of play (ie metro times) by the listed factor for all playheads
      • R: randomize the total pattern (incl period and beats, but not the effect settings; beats of 1/32 are not included in the possibilities)
      • CL: clear, set all beats to "0", i.e. off
      • U: undo random; return to the previously opened or saved preset, ie. not the previous random one
      • M: mute all tracks; the playheads continue moving but audio does not come out of any track
      • ||:pause all playheads; play will resume from that location when un-paused
      • per: period; if 0=randomizes the period, >0 sets the period to be used for all beats
      • Edit Mode
        • Check the [E] to enter edit mode (to cut, copy, or paste selected regions of the pattern)
          • Entering edit mode will pause the playing of the pattern
          • Play, if doing so beforehand, will resume on leavng edit mode
          • The top-left most beat of the pattern grid will be selected when first entering edit mode
        • Single-click a beat to select the top-left corner of the region you wish to cut or copy
        • Double-click a beat to select the bottom-right corner
          • You may not double-click a beat "less than" the single-clicked (top-left) beat and vice-versa
        • Click [CL] to clear your selection (i.e. start over)
        • The selected region will turn to dark colors
        • If only one beat is selected it will be the only one darkened
        • Click the operation (bang) you wish to perform, either cut [CU] or copy [CP]
          • Then, hold down the CTRL key and click the top-left corner of where you want to paste the region
          • The clicked cell will turn white
          • And click [P] to paste the region
        • Cut and copied regions may both be pasted multiple times
          • The difference being, cutting sets the values (gains) for the originating region to "0"
        • Click [UN] to undo either the cut, copy, or paste operation
          • Undoing cut will return the gains from 0s to their original value
      • (effect settings applied to all tracks)
        • co: vcf-cutoff
        • Q: vcf-q
        • del: delay-time
        • fb: delay-feedback
        • dist: distortion
        • reverb
        • gn: gain
    • ABSTRACTIONS
      • $1: [row (idx) b8] (()=a property not an abstraction)
        • GUI
          • (index): aligns with the track number in the KITS section
          • R: randomize the row; same as above, but for the row
          • C: clear the row, i.e. set all beats to 0
          • U: undo the randomize; return to the originally opened one, ie. not the previous random one
          • M: mute the row, so no audio plays, but the playhead continues to play
          • S: solo the row
          • (beat): unit of the beat(period); implying metro length (as calculated with the various other parameters);1/32,1/16,1/8, etc.
          • (pattern): the pattern for the row; single-click on a beat from 0 to 8 times to increment the gain of that beat as a fraction of 1 rms, where resulting rms=value/states; black is rms=0; if all beats for a row =0 (are black) then the switch for that track is turned off; double-click it to decrement it
          • (effects-per-row): same as above, but per-row, ex. first column is vcf-cutoff, second is vcf-q, etc.
        • ABSTRACTIONS
          • $1: b8 (properties:row column)
            • 8-state bang: black, red, orange, yellow, green, light-blue, blue, purple; representing a fraction of rms(gain) for the beat

Credits: The included drum samples are from: https://www.musicradar.com/news/sampleradar-494-free-essential-drum-kit-samples

p.s. Though I began working on cut-copy-paste, it began to pose a Huge challenge, so backed off, in order to query the community as to 1) its utility in the current state (w/o that) and 2) just how important including it really is.

p.p.s. Please, report any inconsistencies (between the instructions as listed and what it does) and/or bugs you may find, and I will try to get an update posted as soon as enough of those have collect.

Love and Peace through sharing,
Scott

Guys thanks so much for you replies, interesting topics especially on the business side.

So to give you a bit more details about the project:

It will be an embedded linux based project, most probably ARM cpu, 16 channels of fixed instruments, and I agree with you about the originality of the concept an here we have in mind many improvements and simplified controls vs the actual and old concepts of grooveboxes to make the musicians feel musicians and not engineers and programers. Obviously its a subjective impression and test it internally by us and we will need gather many other impressions to conclude.

Indeed Organelle was the project made us thinking also about PD but it seems their platform is related to "one time pony patch" and it is not going to a more complex all in one instrument, so thats why my question is coming again, strictly as technical platform is PD reliable for this kind of project?
Also resources wise? Also related to the quality and diversity of the tools available?

Also related to the protection of the work, is there any solution to make the project "closed" ?