New Features, Devices, and Ideas for Pulsar
another $.01
earlier posts in this topic mentioned analogue saturation. Unless I've a mistaken understanding of how this works, I think this would be most valuable if implemented right at the initial A/D conversion. If an anlogue signal with amplitude overflow is coming in on an alugue in, once the conversion is done, the clipping is already part of the digital signal. Not sure whther trying to get it out with subsequent saturation emulation is the right thing.
any of you DSP guys know the answer?
earlier posts in this topic mentioned analogue saturation. Unless I've a mistaken understanding of how this works, I think this would be most valuable if implemented right at the initial A/D conversion. If an anlogue signal with amplitude overflow is coming in on an alugue in, once the conversion is done, the clipping is already part of the digital signal. Not sure whther trying to get it out with subsequent saturation emulation is the right thing.
any of you DSP guys know the answer?
- John Cooper
- Moderator
- Posts: 1182
- Joined: Thu Mar 22, 2001 4:00 pm
- Location: Planet Z
- Contact:
- John Cooper
- Moderator
- Posts: 1182
- Joined: Thu Mar 22, 2001 4:00 pm
- Location: Planet Z
- Contact:
hold up!! i'm planning on making a new wish list forum, which will allow voting/discussion/etc of each "wish". please don't post all your good ideas here, as then i'll have to move them all. the new wish list (and the rest of the site) should be ready in about a week (tho maybe two). it's a huge effort, and i'm spening all my free time on it right now. as i mentioned one of the slow parts about the new wish list will be cleanly migrating the old wish list into the new one (weeding out the cruft, and consolidating the duplicates).On 2001-06-19 00:11, dblbass wrote:
my wishlist for CW
[...snip... lots of good ideas]
A general comment. I trust this thread will grow, bringing out a pretting interesting bunch of ideas.
cheers,
-john
Also, it would be nice to have an area specifically for DEVICE/DEVELOPER level wishes, and then one for CREAMWARE (the OS and hardware, and lower level atoms).
I have a few great ideas for Creamware future hardware.
I'm not sure where my oscillator/filter/VCA with saturation ideas fit. I think either Creamware could do this, or someone who can make custom DSP files....
I have a few great ideas for Creamware future hardware.
I'm not sure where my oscillator/filter/VCA with saturation ideas fit. I think either Creamware could do this, or someone who can make custom DSP files....
Even though I don't think a proper saturator will ever exist on DSP's (again, as a guitar player originally, I'm a bit of a purist & don't even consider my Pod a proper emulation), the Z Driver might be the smoothest one we've got, much more so than Tubulator. It seems to work w/ 2 cascaded distortion modules though a low-pass filter, the last of which is probably why it's so mellow.
The k5000 had an amazing distortion for some reason, it could do out of this world Hendrix tones.
The k5000 had an amazing distortion for some reason, it could do out of this world Hendrix tones.
I have allready tried to make an oscilloscope, it works ok, but the graphics are too slow to monitor music. (oscilloscope uses many "meters") close together, so if the meters are slow, the scope is slow.
it can be used to look at things that are triggered (either externally or by level triggering. so you could examine waveforms with it.
I will not be chucking out my real oscilloscope any time soon!
DeFex
also the screen is really tiny (94 pixels high!) and the resolution is only 47 "dots"
I will make a bigger one if i can figure out how to make a photoshop "action" thet does the graphics automatically, it is very tedious work.
it can be used to look at things that are triggered (either externally or by level triggering. so you could examine waveforms with it.
I will not be chucking out my real oscilloscope any time soon!
DeFex
also the screen is really tiny (94 pixels high!) and the resolution is only 47 "dots"
I will make a bigger one if i can figure out how to make a photoshop "action" thet does the graphics automatically, it is very tedious work.
interesting, defex. sounds like my wish for a proper osscilliscope should stay on the wish list - maybe one of the developers at CW would embrace it as an interestering side project.
meanwhile, another idea for the wishlist:
Group/Ungroup for objects in the pulsar workspace. Shiftclick on two or more devices/modules, then with a menu command or rightclick context menu command, selected objects collapse into a single icon in the project window (maybe a diferent colour to indicate that it is a group, not an individ module). I/O connections would only show those that are external to the group, and the thing could be user-nameable. Doubleclick again to expand, and get back to editing individual components. A seperate (context) menu item to cancel the grouping, accessible from any group member. On expand/collapse, other projects in the project workspace surrounding the group would move closer together or spread out (vertically and horizontally).
Sorta like using ModII, but not so rigid, this would enable more creative managagement of project views and thinking about functions and groups of funtions in a more heirarhial fashion.
meanwhile, another idea for the wishlist:
Group/Ungroup for objects in the pulsar workspace. Shiftclick on two or more devices/modules, then with a menu command or rightclick context menu command, selected objects collapse into a single icon in the project window (maybe a diferent colour to indicate that it is a group, not an individ module). I/O connections would only show those that are external to the group, and the thing could be user-nameable. Doubleclick again to expand, and get back to editing individual components. A seperate (context) menu item to cancel the grouping, accessible from any group member. On expand/collapse, other projects in the project workspace surrounding the group would move closer together or spread out (vertically and horizontally).
Sorta like using ModII, but not so rigid, this would enable more creative managagement of project views and thinking about functions and groups of funtions in a more heirarhial fashion.
Okay here are a few suggestions for Creamware hardware.
1. A computer box that runs ONLY Pulsar. It would have a monitor out, keyboard/mouse input, but no OS, no sequencer. As close to a sound-module as possible, so 1U or 2U (4U at most!) and allow multiple cards to upgrade it. It would have to be slick and as stable as a hardware synth. I think this could even be pulled off on Windows, as long as you deleted nearly everything and had it optimized. Perhaps it would even just have a FireWire connector on it, so you could plug it into a FireWire enabled laptop/PC and run it sort of like a Kyma system. Also build some type of RAM into it, so there isn't PCI bus issues.
A similiar solution would be to put Creamware cards into a "Magma PCI Expander" however due to the PCI bus issues, you wouldn't be able to do very much with such a solution.
2. If the first suggestion seems unlikely, how about some sort of VERY knobby (30 or more knobs and sliders) desktop module, similiar to an Access Virus or Waldorf Q rack, which can run ANY sort of algorythm(sic) on the Pulsar system, but has 4 inputs, 4 outputs (MIDI i/o/thru), and a touch screen built into it. Again, it would probably run on a computer-like system, so a VERY slim/stable version of windows. The display would be integrated, and the pointing device would be your finger (see Korg Triton only larger and CoLoR) -- Sort of like a rack version of <img src=http://www.harmony-central.com/Newp/Mus ... ame-1S.jpg> the frame One. It would come with a 3 SHARC card stock, but have the ability to add a Pulsar and/or SCOPE card for more Voices!
3. A keyboard version of #2.
4. A *cheap* version of the Luna2 card, only without the DSPs (or only 1 DSP). We're talking sub $200 audio card. Something to kill the Echo Mia.
5. A decent rackmount converter with Z-link. Nothing against the Luna Box (excellent price!), but many musicians prefer rackmount form factor, and 1/4" inputs instead of RCA.
6. I got this idea from the Creamware forum. A way to connect two machines running Creamware cards by connecting the Z-link connector on both machines for 8 channels back and forth.
7. A driver to capture video on the FireWire ports, giving you a VideoCapture card on your Luna2 (not sure if that's even possible.. cool idea though).
8. More *dedicated* premapped hardware controllers. Support from larger companies like the support ProTools gets. Easier integration; simply load a patch called "Saturn" on the hardware device to control every knob of the Pulsar Saturn synth, for example. Yes, I realize you can map everything easily yourself. Some people don't seem to understand this, and seeing "actual, direct" support written on the hardware controller for "Creamware" would help.
That's just off the top of my head, and just hardware stuff. BTW these ideas are COPYRIGHT 2001
1. A computer box that runs ONLY Pulsar. It would have a monitor out, keyboard/mouse input, but no OS, no sequencer. As close to a sound-module as possible, so 1U or 2U (4U at most!) and allow multiple cards to upgrade it. It would have to be slick and as stable as a hardware synth. I think this could even be pulled off on Windows, as long as you deleted nearly everything and had it optimized. Perhaps it would even just have a FireWire connector on it, so you could plug it into a FireWire enabled laptop/PC and run it sort of like a Kyma system. Also build some type of RAM into it, so there isn't PCI bus issues.
A similiar solution would be to put Creamware cards into a "Magma PCI Expander" however due to the PCI bus issues, you wouldn't be able to do very much with such a solution.
2. If the first suggestion seems unlikely, how about some sort of VERY knobby (30 or more knobs and sliders) desktop module, similiar to an Access Virus or Waldorf Q rack, which can run ANY sort of algorythm(sic) on the Pulsar system, but has 4 inputs, 4 outputs (MIDI i/o/thru), and a touch screen built into it. Again, it would probably run on a computer-like system, so a VERY slim/stable version of windows. The display would be integrated, and the pointing device would be your finger (see Korg Triton only larger and CoLoR) -- Sort of like a rack version of <img src=http://www.harmony-central.com/Newp/Mus ... ame-1S.jpg> the frame One. It would come with a 3 SHARC card stock, but have the ability to add a Pulsar and/or SCOPE card for more Voices!
3. A keyboard version of #2.
4. A *cheap* version of the Luna2 card, only without the DSPs (or only 1 DSP). We're talking sub $200 audio card. Something to kill the Echo Mia.

5. A decent rackmount converter with Z-link. Nothing against the Luna Box (excellent price!), but many musicians prefer rackmount form factor, and 1/4" inputs instead of RCA.
6. I got this idea from the Creamware forum. A way to connect two machines running Creamware cards by connecting the Z-link connector on both machines for 8 channels back and forth.
7. A driver to capture video on the FireWire ports, giving you a VideoCapture card on your Luna2 (not sure if that's even possible.. cool idea though).
8. More *dedicated* premapped hardware controllers. Support from larger companies like the support ProTools gets. Easier integration; simply load a patch called "Saturn" on the hardware device to control every knob of the Pulsar Saturn synth, for example. Yes, I realize you can map everything easily yourself. Some people don't seem to understand this, and seeing "actual, direct" support written on the hardware controller for "Creamware" would help.
That's just off the top of my head, and just hardware stuff. BTW these ideas are COPYRIGHT 2001

Wow, no comments on my ideas. I guess everyone is running to the patent office quietly in the background then? 
A few more suggestions for the next Pulsar version:
1. If a user has some CW cards already (example, a Pulsar1), then installs a Luna2 card, the installer should:
<ul>
a. automatically install the driver for the card (currently, the installer will install the software, and when you try to run it, you get an invalid/no hardware error message!) -- no user intervention should be required to install the driver for the card.
b. if another card is found (Pulsar1 or any combination), then the installer should ask for your device directory (autodetect it, then confirm with the user), <b>install the plugins from the new card automatically to your current creamware device directory</b>, and <b>not install the "lesser" software</b> (in this case, the Luna2 software should NOT be installed).
</ul>
2. Better error messages and error handling. Only pop up an error box when ABSOLUTELY necessary. This means "reorganize DSPs" should hardly ever appear, it should try until it realizes there isn't enough DSP, then give you a message "Not enough DSP, unload a device & try again" -- and not pop up the same error message more than once @ most -- pressing retry a million times (I've seen users do this!) shouldn't be an option.
3. Perhaps this is related to the "mini Luna2" request from my previous "Hardware" suggestions post, but a way for someone without DSPs to load the Pulsar software, and load devices, play with routing & patching without owning a full on DSP card. The "DSP" meter might still move so you can get an idea of load. Perhaps this could even be just a "simple" (hah right) interactive FLASH demonstration, but it should act the same as the real thing. You could even put this on a webpage so people could play with it and realize it's power before buying.
4. it's been said 100,000 times before, but AT LEAST one level of Undo. I accidently remove a wire in a Modular2 patch, and just want to press "Control Z" to put it back, only that doesn't work
Lots more where that came from, but those things would help quite a bit.
Let's try our best not to mention things that have already been mentioned a lot in the past though if possible...

A few more suggestions for the next Pulsar version:
1. If a user has some CW cards already (example, a Pulsar1), then installs a Luna2 card, the installer should:
<ul>
a. automatically install the driver for the card (currently, the installer will install the software, and when you try to run it, you get an invalid/no hardware error message!) -- no user intervention should be required to install the driver for the card.
b. if another card is found (Pulsar1 or any combination), then the installer should ask for your device directory (autodetect it, then confirm with the user), <b>install the plugins from the new card automatically to your current creamware device directory</b>, and <b>not install the "lesser" software</b> (in this case, the Luna2 software should NOT be installed).
</ul>
2. Better error messages and error handling. Only pop up an error box when ABSOLUTELY necessary. This means "reorganize DSPs" should hardly ever appear, it should try until it realizes there isn't enough DSP, then give you a message "Not enough DSP, unload a device & try again" -- and not pop up the same error message more than once @ most -- pressing retry a million times (I've seen users do this!) shouldn't be an option.
3. Perhaps this is related to the "mini Luna2" request from my previous "Hardware" suggestions post, but a way for someone without DSPs to load the Pulsar software, and load devices, play with routing & patching without owning a full on DSP card. The "DSP" meter might still move so you can get an idea of load. Perhaps this could even be just a "simple" (hah right) interactive FLASH demonstration, but it should act the same as the real thing. You could even put this on a webpage so people could play with it and realize it's power before buying.
4. it's been said 100,000 times before, but AT LEAST one level of Undo. I accidently remove a wire in a Modular2 patch, and just want to press "Control Z" to put it back, only that doesn't work

Lots more where that came from, but those things would help quite a bit.
Let's try our best not to mention things that have already been mentioned a lot in the past though if possible...
- John Cooper
- Moderator
- Posts: 1182
- Joined: Thu Mar 22, 2001 4:00 pm
- Location: Planet Z
- Contact:
so, i never heard back from anyone at creamware germany (and i cc'd every one i know at CW!)On 2001-06-19 08:39, John Cooper wrote:ha! well, i'll send an email to them and let them know they should have a look here!On 2001-06-19 05:15, Spirit wrote:
I don't think CW even read their OWN site.
-john
i know they're very busy with 3.0, so there's a possibility they're not reading these ideas unfortunately.

-john
More "Less mainstream" type freebe devices etc would be great. After all we have all spent a lot of money on creamware stuff so maybee some more tools and proffesional effect devices that arent so freeware ish. Perhaps when V3 is firing on all 8 Creamware might want to spend a little time on some of the excellent suggestions in this thread.
Nigel.
Nigel.
Another hardware suggestion. This is the "big one."
Pulsar3/Luna3(or something entirely dedicated to this task) -- comes with on-board RAM -- maybe even one (two?) DDR slot or SDRAM slot (angled) -- accepting up to 256megs or 512megs. Connects via STDM as usual, and any device that is coded to use main memory would instead go through the STDM to the memory on the MkIII board.
Crazy implementation ideas:
InsanitySampler - Luna3 card, 2 slots for RAM & 512meg limit - doesn't use the PCI bus, and 2 STDM connectors. Maybe 4 SHARCs. Comes with STS4000, upgradable to STS5000 (hey it could happen! and pigs can fly!)
Pulsar3 - Pulsar2 with SDRAM/DDR slot or 2, 8 SHARCs maybe (6 is fine too), and 3 STDM connectors.
The idea would be to redirect all PCI bus traffic through STDM connectors (and move towards having 2 STDM cables between all cards), thus avoiding PCI issues, and making cheaper currently "crap" VIA chipsets a non-issue.
I've mentioned this idea around a year ago on Pulsar-scope. Okay, done dreaming... sorry about that
Pulsar3/Luna3(or something entirely dedicated to this task) -- comes with on-board RAM -- maybe even one (two?) DDR slot or SDRAM slot (angled) -- accepting up to 256megs or 512megs. Connects via STDM as usual, and any device that is coded to use main memory would instead go through the STDM to the memory on the MkIII board.
Crazy implementation ideas:
InsanitySampler - Luna3 card, 2 slots for RAM & 512meg limit - doesn't use the PCI bus, and 2 STDM connectors. Maybe 4 SHARCs. Comes with STS4000, upgradable to STS5000 (hey it could happen! and pigs can fly!)
Pulsar3 - Pulsar2 with SDRAM/DDR slot or 2, 8 SHARCs maybe (6 is fine too), and 3 STDM connectors.
The idea would be to redirect all PCI bus traffic through STDM connectors (and move towards having 2 STDM cables between all cards), thus avoiding PCI issues, and making cheaper currently "crap" VIA chipsets a non-issue.
I've mentioned this idea around a year ago on Pulsar-scope. Okay, done dreaming... sorry about that

Well, Creamware must be listening cause I just saw a pig fly by my window. No, seriously, you can get the STS5000 for Pulsar & Luna now, and there is even *gasp* an upgrade to get STS5000 if you've already got STS4000! I honestly didn't think they'd do this, but it's absolutely a step in the right direction. THANK YOU.
-
- Posts: 1139
- Joined: Tue Apr 03, 2001 4:00 pm
- Location: Tennessee, USA
- Contact: