COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :
Old 11-04-2011, 03:10 PM   #1
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default Let's continue Ninjam development!

Ninjam is a great piece of software because it allows musicians from across the world to play together. The stand-alone clients and server seem to no longer be under development and the code risks "bitrotting" to the point where it no longer works.

I recently fixed up the curses client for Linux x86-64. After seeing all the various "Ninjam doesn't compile under ..." posts on this forum it is clear that we need to actively maintain the code.

People have also created interesting patches to extend the clients or protocol. And much more can be done if it is possible to get those patches merged into new releases.

As a first step I have created a git repository that contains the Windows, Mac OS X, and curses stand-alone clients. It also contains the server:

http://github.com/stefanha/ninjam

Next, we need to find more people who are willing to review and merge patches for the Windows client, Mac OS X client, and server. (I am happy to support the curses client.)

At that point we can register a domain, fork Ninjam under a new name, and run an active open source project that continues to improve Ninjam and make it available to users. If Justin/Cockos allow it, maybe the project can take on the official Ninjam name rather than being a fork.

In summary:
* In order to continue developing Ninjam we need an open source project.
* If you want to help maintain the stand-alone clients or server, please reply.
* If you have patches you'd like included, please reply.
stefanha is offline   Reply With Quote
Old 11-05-2011, 01:25 AM   #2
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 580
Default

Great idea, best of luck. I wish I had time to help out! Maybe late next year...
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.
pljones is offline   Reply With Quote
Old 11-05-2011, 10:37 AM   #3
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

pljones: Glad to hear you like you this.

I took the next steps today. Choosing a name is really hard since so many domain names are already taken. After playing around with different possibilities I chose Wahjam. Wah-wah is an awesome effect and I hope people like the name .

There is now a wiki and an official Wahjam git repository available at http://wahjam.org/.

This is all hosted on Github, so for those who already have accounts it should be familiar and convenient. It's a great chance to try Git if you haven't used it before.

The IRC channel is #wahjam on irc.oftc.net. I am idling on there and will participate when I'm around.

How to get involved

For web designers, consider what the Wahjam website should look like. The wiki is for information that anyone can edit but http://wahjam.org/ should have its own static frontpage that showcases the software and provides download links.

For developers, please try to build the code at http://wahjam.org/. Shout if it fails to build, or even better, submit patches to fix the problem.

If you have patches for the clients or server, please reply so they can be merged.
stefanha is offline   Reply With Quote
Old 11-06-2011, 02:21 PM   #4
DaMNeD
Human being with feelings
 
Join Date: Oct 2008
Location: Aix en Provence, France
Posts: 38
Default

Good idea and nice job.
You can grab the corrected ninjamcast I made for compiling under Ubuntu X64, didn't test on other platform (just corrected some vars). It's earlier as an attachemnt in the forum.

I think I still have somewhere too the xcode project for the ninjam osx client side which works under Lion, though just compiled it and tested connect, didn't test jam with it.

Anyway, most of 'advanced' (note the quote) users of ninjam are using reaper reaninjam vst plugin to connect there.
I think there has been some improvement in the code there, but it's closed source.

So a good point would be 1st to determine what / where / which direction to go, and what should be tried to be made, on each point.

Just to list some ideas :

- Ninjam Client as a Cross platform VST Plugin to use it in any daw,
- Improvements on server side, adding some new voting commands (.. vote kick.. , improvement of the chat side of the servers, recording management, etc..),
- Update of the clients to support more audio channel/inputs, redesign of ui, more user preference (metronome tone for example), recording management)
- etc...

PS : I'm not a dev, but I can try to help
__________________
http://ninjamer.com - Ninjam public servers - Jamers Community
"Some are talking a lot, and not doing much, while others are doing much, and not talking a lot".
Support Cockos, if you like Ninjam, and use it a lot, Purchase REAPER here -> http://www.reaper.fm/purchase.php
DaMNeD is offline   Reply With Quote
Old 11-06-2011, 03:39 PM   #5
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

DaMNeD: Thanks for the ninjamcast link. There are no GPL license headers on this code so I'll try to get in touch with Brennan first before merging it. In theory it must be GPL compatible since it uses common GPL Ninjam code, but it's worth being careful so there is no doubt about licenses later.

The direction is a good question and is being influenced by the people who get involved.

Release 1.0 is about providing a fixed but mostly unchanged client/server to end users:
  • Website that provides downloads and screenshots
  • Manually tested builds on Windows, Mac OS X, and Linux
  • Bug fixes

Once that baseline is reached the fun really begins .

My personal goals after 1.0 are to focus on the easy-to-use and stand-alone aspects. That means making a great cross-platform client for musicians who are not audio pros or DAW users.

ReaNinjam caters to the audio pros so I don't personally want to work on VST or other audio plugins. Leaving that space untouched is also a way of giving Reaper some love.

There's a lot of cool stuff that could be done for a stand-alone client:
  • Your points (redesigned GUI, metronome tweaks, etc)
  • Built-in server browser
  • Built-in looper
  • Built-in tuner
  • Easy drum loop or mp3 playback channel
  • Crowd-source and bundle free drum loops (Creative Commons licensed?)

I also really want to document the Ninjam network protocol on the wiki for the benefit of everyone hacking on Ninjam-related software.
stefanha is offline   Reply With Quote
Old 11-07-2011, 02:25 AM   #6
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 580
Default

The server browser is pretty trivial, you could probably include that in your 1.0 with nearly no effort.
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.
pljones is offline   Reply With Quote
Old 11-07-2011, 10:30 AM   #7
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Now that the project hosting, wiki, and code repository are set up at http://wahjam.org/ we can begin shaping up the 1.0 release.

We need maintainers for the Windows and Mac OS X clients, as well as the server. Here's what maintainers do:
  • Get the build working on their platform
  • Help me set up automated builds for testing and releases
  • Review and test patches which affect their platform

You don't need to write lots of code to be the maintainer. It's more about being able to check that adding new patches does not break your platform.

So if you try out Wahjam and get it working on Windows or Mac OS X, please consider replying and becoming a maintainer!
stefanha is offline   Reply With Quote
Old 11-14-2011, 04:55 PM   #8
AndyMc
Human being with feelings
 
AndyMc's Avatar
 
Join Date: Dec 2006
Posts: 441
Default

I'd like to see more in ways of web browsing in the form of a sound cloud as well as access to the ninjam auto record archive, then these could stream through a persons client.
Then we could have maybe a user section to upload sounds, but if configurable people could also use dropbox, shared folders and all sorts of online sources.

The Stereo channel routed correctly from Stereo Source.

Simple Audio Selection and auto latency measuring to show a user there estimated latency.
In line with this maybe a Direct Monitor option, so if a persons latency is too high for local loopback channel then a direct monitor option could mute local and use original source.

An Auto Levelling option that could with one click adjust all users volume sliders to get an even mix, maybe even a realtime normalize function to fix low output's on a client's output.

User's Channels to ASIO Channels, so user 1 = 1/2 user 2 = 3/4 and so on, this will be useful for live events, then the main audio streamer could route these outs into REAPER or other DAW or Audio Host.
This would allow Eq'ing, other FX's and better mixing for the final out the listener would hear.

Maybe rather than adding addition features these could be more a app based system, so people could write app's for NINJAM, which then some programmers could even sell which will encourage people to program more for it and more to use it.
On this same idea maybe if possible to even give NINJAM VST Host abilities too.

One last thing, maybe adding direct streaming capabilities to NINJAM. So it in fact becomes a small suite which could remember settings/fx's and similar for each other user from there IP.

Most these things will bring more users towards NINJAM as it becomes more desired for its additional properties.

Just some idea's, some maybe achievable, some not. I guess if REAPER's ReaNINJAM was updated some of this would already be there as part of REAPER.
__________________
Latest Shit (looking for singers): http://www.soundcloud.com/AndyMcProducer
Twitter (@AndyMcProducer): http://www.twitter.com/AndyMcProducer
Facebook Page: http://www.facebook.com/AndyMcProducer

Last edited by AndyMc; 11-14-2011 at 05:01 PM.
AndyMc is offline   Reply With Quote
Old 11-14-2011, 11:36 PM   #9
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

> Simple Audio Selection and auto latency measuring to show a user there estimated latency.
> In line with this maybe a Direct Monitor option, so if a persons latency is too high for local loopback channel then a direct monitor option could mute local and use original source.

I played with monitoring latency on the weekend because it bothers me that there is an audible delay. After adding some instrumentation I found that the estimated latency of 5 ms was not being achieved, in practice the latencies were all over the place, often 15-20 ms.

Achieving good monitoring performance in Ninjam will require refactoring the audio processing callback. It does way too much work today, including some calls that may block.

As a test I ran just the audio code copying input to output without the rest of Ninjam and latencies never reached 15-20 ms, they were lower and more predictable.

So at the moment I find the software monitoring a bit of a mis-feature since it performs poorly. These low latency issues are only a problem if we want to support software monitoring. The rest of Ninjam does not need low latency.

> An Auto Levelling option that could with one click adjust all users volume sliders to get an even mix, maybe even a realtime normalize function to fix low output's on a client's output.

Yes! Awesome idea. It can be a chore when different users come in at different volume levels and you need to tweak it manually. Since the client has audio data for the next interval it can easily look into the "future" to normalize levels.

> User's Channels to ASIO Channels, so user 1 = 1/2 user 2 = 3/4 and so on, this will be useful for live events, then the main audio streamer could route these outs into REAPER or other DAW or Audio Host.
> This would allow Eq'ing, other FX's and better mixing for the final out the listener would hear.

This sounds like you don't want Ninjam to do mixing. Instead it should output all channels to a software routing system (ASIO, JACK, etc). This is definitely doable although it's something that ReaNinjam could do instead of the stand-alone client. But if someone contributes patches for this I'd merge it.

> Maybe rather than adding addition features these could be more a app based system, so people could write app's for NINJAM, which then some programmers could even sell which will encourage people to program more for it and more to use it.
> On this same idea maybe if possible to even give NINJAM VST Host abilities too.

In theory a Ninjam client could be implemented as a VST host and each component in the audio path could be a plugin. That would be very flexible but also means a more complex user interface where maybe a DAW is better suited.

My feel on these sorts of features is that Wahjam as a stand-alone Ninjam client should be simple and allow a musician to get jamming without knowledge of digital audio or recording. Users who want to tweak the signal chain and have total control would go with ReaNinjam.

Thanks for sharing your ideas!
stefanha is offline   Reply With Quote
Old 12-16-2011, 08:51 AM   #10
turion
Human being with feelings
 
Join Date: Jul 2011
Posts: 9
Default

So I take it that wahjam is now the best option for a linux client of ninjam?

I want to contribute to this by starting an archlinux package containing up to date wahjam.

It seems there is a JACK-backend available under http://www.gehrignet.de/cms.shtml?programming/ninjam. We should try to include this into wahjam.
turion is offline   Reply With Quote
Old 12-16-2011, 09:56 AM   #11
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

> So I take it that wahjam is now the best option for a linux client of ninjam?

It is actively maintained and builds on modern distros. If you hit any issues please get in touch via #wahjam IRC on irc.oftc.net or wahjam@googlegroups.com.

> I want to contribute to this by starting an archlinux package containing up to date wahjam.

Fantastic! I've been using wahjam's cursesclient on Debian amd64.

The missing piece for packaging is that things are still named 'ninjam'. This isn't ideal since it could conflict for users who have both wahjam and ninjam installed on the same system. Also, it could confuse users so I intend to fix this:

https://github.com/wahjam/wahjam/issues/3

I'll try to get that fixed this weekend.

> It seems there is a JACK-backend available under http://www.gehrignet.de/cms.shtml?programming/ninjam. We should try to include this into wahjam.

I have started revamping the code with the goal of a single QT-based client GUI that uses PortAudio to handle audio. The big advantage of this is that a single codebase would build on Linux, Windows, and Mac so any features or tweaks added benefit all platforms. PortAudio has a JACK backend so we'll get that for free when moving to PortAudio (which Audacity also uses).

I haven't published the qtclient branch yet but will try to get that online soon too.

The best place to chat more about the details of packaging is #wahjam IRC on irc.oftc.net or wahjam@googlegroups.com. I'll be happy to help you get this working.
stefanha is offline   Reply With Quote
Old 12-16-2011, 03:54 PM   #12
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 580
Default

It would be better to target JACK natively. JACK runs on Windows, OSX and Linux and you may avoid the latency issues going via PortAudio may risk.
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.
pljones is offline   Reply With Quote
Old 12-17-2011, 11:21 AM   #13
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

> It would be better to target JACK natively. JACK runs on Windows, OSX and Linux and you may avoid the latency issues going via PortAudio may risk.

I agree it would be technically better: portable audio API with low latency and flexible routing options. However it requires that users install JACK, configure it, and run the daemon:

http://jackaudio.org/jack_on_windows

Users who simply connect their instrument do not need routing. Even experienced digital audio users may not know JACK if they are on Windows or Mac. Requiring JACK adds an extra step (and things that can go wrong) that is only needed for software instruments, VSTs, etc.

I think native JACK would be a hurdle to the "plug in your instrument and start jamming" experience.

Latency actually does not worry me. Ninjam is not latency-sensitive because the audio is buffered. The only low-latency part of Ninjam is software monitoring (unmuting yourself), which does not work well today anyway because the code does not take real-time precautions (avoiding memory allocations, no blocking operations, pinning memory, etc).
stefanha is offline   Reply With Quote
Old 12-17-2011, 12:46 PM   #14
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Turion: I have replaced "NINJAM" with "Wahjam" so that this is a little more packagable .

The client binary is now called cwahjam (instead of cninjam) and the server is called wahjamsrv (instead of ninjamsrv). You can download and build the code like this:

Code:
$ git clone git://github.com/wahjam/wahjam.git
$ cd wahjam/ninjam/cursesclient
$ make # produces cninjam
$ cd ../server
$ make # produces wahjamsrv
For any rough edges that you hit please email wahjam@googlegroups.com or send patches.
stefanha is offline   Reply With Quote
Old 12-18-2011, 06:37 AM   #15
turion
Human being with feelings
 
Join Date: Jul 2011
Posts: 9
Default

Thanks, folks! I'm "maintaining" an archlinux package of the client here: https://aur.archlinux.org/packages.php?ID=55075
It compiled smoothly without serious warnings, so that's already an improvement over the old ninjam client.

About the JACK/PortAudio question: We should have both, I think.
Most serious musicians under Linux will configure JACK one day, so they are happy if there is a simple JACK backend. I myself would use it and nothing else.
PortAudio is nice for easy portability, so we shouldn't leave it out as well.
But JACK available only over PortAudio only makes it harder for the JACK users under Linux. One more piece of software to configure, one more layer of bugs...

Last edited by turion; 12-18-2011 at 06:43 AM.
turion is offline   Reply With Quote
Old 12-18-2011, 07:25 AM   #16
turion
Human being with feelings
 
Join Date: Jul 2011
Posts: 9
Default

About ninjam and latency: If you're playing with only one instrument, latency is no problem.
If you play with several instruments and software effects, latency is a huge problem and a low latency sound server like JACK is necessary.
Since electronic music is the kind of music most ninjam users will make, the latter usecase will be quite common. So let's have a native JACK backend.
turion is offline   Reply With Quote
Old 12-18-2011, 08:28 AM   #17
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Turion: Thanks for publishing the package!

I'm not sure I understand the latency requirement with multiple instruments. Ninjam keeps audio data in separate channels - it will not mix multiple instruments from your PC together. Each instrument's audio data is uploaded in its own channel and there is no explicit time synchronization between channels, instead they are assumed to be in sync frame-by-frame.

Can you explain where latency matters?
stefanha is offline   Reply With Quote
Old 12-19-2011, 10:21 AM   #18
turion
Human being with feelings
 
Join Date: Jul 2011
Posts: 9
Default

Quote:
Originally Posted by stefanha View Post
Ninjam will not mix multiple instruments from your PC together.
That's exactly the reason. If I would do a jam, I would have e.g. a looping program, my midi keyboard and my electric base plugged in and some software effects running. I would mix and process all of them together with JACK and send the resulting single stream to the server. Of course, I don't want latency between a key press of the keyboard and the master stream in my earphones, so I'm using JACK on my local computer.

I assume that it will be possible to just take the JACK output and send it to the ninjam client with Portaudio. A solution without PortAudio would be preferable, though.
turion is offline   Reply With Quote
Old 12-19-2011, 11:26 AM   #19
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 580
Default

Quote:
Originally Posted by turion View Post
Of course, I don't want latency between a key press of the keyboard and the master stream in my earphones, so I'm using JACK on my local computer.
I hope you mean you're sending through NINJAM and then to your earphones. If you're not, you're set up wrong.
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.
pljones is offline   Reply With Quote
Old 12-19-2011, 12:49 PM   #20
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Quote:
I assume that it will be possible to just take the JACK output and send it to the ninjam client with Portaudio. A solution without PortAudio would be preferable, though.
Yes, you can do that although I think the usual approach is to send separate channels to Ninjam instead of mixing inputs together on the client.

I wrote a little PortAudio test program last night to get a feel for how it interacts with JACK. It has the ability to create multiple inputs/outputs which you can route in JACK as normal. PortAudio is really just a client library, there's no server and no special configuration involved so I don't expect the user to know the difference between a native JACK app and a PortAudio app.

Thanks for pushing me in the direction of investigating JACK more. It has a nice model that I'm trying to keep in mind.

I will proceed by doing all audio through PortAudio because I think it can integrate seemlessly with JACK. I'll ask for feedback and if you find it just doesn't work as well as native JACK then we can add that too.

Another idea is that some audio systems like PulseAudio support mixing to the point where we don't need to do mixing inside Ninjam for audio playback. So imagine each remote user's channels become output ports that you can then route how you like in JACK - instead of just one Ninjam output port with mixed audio. I'm not sure yet if there are practical benefits because Ninjam will still have to support a playback mixer for sound backends that do not always provide mixing (e.g. ALSA). Can you think of situations where this would be a useful feature?
stefanha is offline   Reply With Quote
Old 12-20-2011, 01:19 AM   #21
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 580
Default

Quote:
Originally Posted by stefanha View Post
Yes, you can do that although I think the usual approach is to send separate channels to Ninjam instead of mixing inputs together on the client.
But that's not necessarily a good thing. It's a better approach for one NINJAM user to have sorted out their mix than for every other user to have to do it for them. A single stereo feed into NINJAM is all that's really needed.
Quote:
Originally Posted by stefanha View Post
Another idea is that some audio systems like PulseAudio support mixing to the point where we don't need to do mixing inside Ninjam for audio playback.
How are you checking the latency of these things? I think PulseAudio would stop anyone using the system seriously other than to play back pre-recorded music. It would stop any form of live music creation.
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.
pljones is offline   Reply With Quote
Old 12-20-2011, 02:41 AM   #22
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Quote:
But that's not necessarily a good thing. It's a better approach for one NINJAM user to have sorted out their mix than for every other user to have to do it for them. A single stereo feed into NINJAM is all that's really needed.
I can only guess at the reason why (Brendan/Justin's thoughts would be interesting) but I think the reason is so that offline editing/mixing is possible. If clients send pre-mixed audio then there are fewer editing possibilities afterwards if you want to make a nice MP3 from the jam. At least the cliplogcvt utility that comes in the Ninjam source tree is geared towards importing your ninjam session in a DAW so you can mix it afterwards.

In practice I've never edited/mixed jams after playing though .

Quote:
How are you checking the latency of these things? I think PulseAudio would stop anyone using the system seriously other than to play back pre-recorded music. It would stop any form of live music creation.
I haven't checked the latency on PulseAudio. If you want to use software instruments/effects then JACK is probably required.

In the case of a single physical instrument plugged in to the PC it's not an issue though. My setup is based around a guitar effects processor with USB audio. It has built-in monitoring so I don't worry about the latency of my own signal. Ninjam is playing remote user audio into the guitar effects processor which mixes it together with the monitor signal. Both the instrument and the headphones are plugged into the guitar effects processor.
stefanha is offline   Reply With Quote
Old 12-20-2011, 08:08 AM   #23
turion
Human being with feelings
 
Join Date: Jul 2011
Posts: 9
Default

Quote:
Originally Posted by stefanha View Post
I can only guess at the reason why (Brendan/Justin's thoughts would be interesting) but I think the reason is so that offline editing/mixing is possible. If clients send pre-mixed audio then there are fewer editing possibilities afterwards if you want to make a nice MP3 from the jam.
I think it's better to just send the live mixed stream to the server and record all the single channels offline at the same time. (Easy exercise with JACK)
Later, you could just remaster the whole jam, if you wanted.
There is no need to send the individual channels up to the server if the other users don#t want to do *their live mix/edit* of your channels.

About PortAudio: Right, better concentrate on the PortAudio backend and see if it is good enough already.
turion is offline   Reply With Quote
Old 12-20-2011, 08:39 AM   #24
pljones
Human being with feelings
 
pljones's Avatar
 
Join Date: Aug 2007
Location: London, UK
Posts: 580
Default

Quote:
Originally Posted by stefanha View Post
Ninjam is playing remote user audio into the guitar effects processor which mixes it together with the monitor signal. Both the instrument and the headphones are plugged into the guitar effects processor.
With this set up, you can't tell if you're playing in time with the NINJAM click. Don't do this. You need to ensure that the only audio you hear has been through NINJAM. Always, regardless of how it's produced. No bypassing is necessary (or "allowed" ), if you're not introducing latency (above about 10ms, which should be unnoticeable).

Client-wise, personally, I don't think any of the sliders are helpful - I'd get rid them all. Having all channels fixed at the same level -- rather than local defaulting to +12dB above remote -- would help simplify the user experience. Maybe allow the local channel to have a +3dB boost to help monitoring (clearly labelled). Maybe allow the click to have a +3dB boost, too... (and allow its sound to be changed...)
__________________
Quote:
Originally Posted by Tony Williams
...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world.
pljones is offline   Reply With Quote
Old 12-21-2011, 04:56 AM   #25
turion
Human being with feelings
 
Join Date: Jul 2011
Posts: 9
Default

A completely different issue:
Shouldn't wahjamsrv create a default config.cfg and store it in ~/.wahjamsrv?
turion is offline   Reply With Quote
Old 01-19-2012, 02:13 AM   #26
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Quote:
Originally Posted by turion View Post
A completely different issue:
Shouldn't wahjamsrv create a default config.cfg and store it in ~/.wahjamsrv?
Have you seen the ninjam/server/example.cfg file? You can use it as a template for configuring the server. In a Linux package it would probably live in /usr/share/doc/wahjamsrv/example.cfg or similar.

If you or anyone else wants to improve the server we can merge patches.
stefanha is offline   Reply With Quote
Old 01-19-2012, 02:23 AM   #27
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Quote:
Originally Posted by pljones View Post
Client-wise, personally, I don't think any of the sliders are helpful - I'd get rid them all. Having all channels fixed at the same level -- rather than local defaulting to +12dB above remote -- would help simplify the user experience. Maybe allow the local channel to have a +3dB boost to help monitoring (clearly labelled). Maybe allow the click to have a +3dB boost, too... (and allow its sound to be changed...)
I will try this. It will be important to have a VU meter for local channels showing you if they are too quiet/loud, because this cut-down UI depends on each user setting a reasonable input volume.

The Qt client is available here:
https://github.com/wahjam/wahjam/tree/qtclient
stefanha is offline   Reply With Quote
Old 09-15-2012, 02:06 PM   #28
Hooserdaddy
Human being with feelings
 
Join Date: Nov 2010
Posts: 4
Default Feature request

Interesting to see you guys working on this. One thing that would help me dramatically is a MIDI sync message out of Ninjam so that I can sync up external DAWs.

I imagine it would take creating a MIDI port then send the timing out. The external DAW would open it and use. Would make a dramatic improvement for me and surely others (I like Ableton Live).

I was wondering, could you baseline off the source code used in the ReaNINJAM version 0.13 that comes with Reaper? It seems to have many more features than the screenshots on your Wahjam website. Suppose they just won't release the source...
Hooserdaddy is offline   Reply With Quote
Old 09-15-2012, 10:44 PM   #29
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Quote:
Originally Posted by Hooserdaddy View Post
Interesting to see you guys working on this. One thing that would help me dramatically is a MIDI sync message out of Ninjam so that I can sync up external DAWs.

I imagine it would take creating a MIDI port then send the timing out. The external DAW would open it and use. Would make a dramatic improvement for me and surely others (I like Ableton Live).
Thanks for the suggestion. There is an open Issue on the Wahjam GitHub page to add MIDI Sync support:
https://github.com/wahjam/wahjam/issues/20

Quote:
Originally Posted by Hooserdaddy View Post
I was wondering, could you baseline off the source code used in the ReaNINJAM version 0.13 that comes with Reaper? It seems to have many more features than the screenshots on your Wahjam website. Suppose they just won't release the source...
As far as I know ReaNINJAM is closed source. The open source NINJAM code does contain features you may be thinking of - like voice chat and session mode. These just haven't been exposed in the Wahjam user interface but the code is there waiting to be hooked up.

Which ReaNINJAM features are you particularly interested in?
stefanha is offline   Reply With Quote
Old 09-16-2012, 09:24 PM   #30
Hooserdaddy
Human being with feelings
 
Join Date: Nov 2010
Posts: 4
Default

Wow quick response! I'll actually have to try your version and get back to you on features, just noting what I see on the ReaNINJAM screen vs. what I've seen in your snapshots, maybe there's more than what meets the eye. I really just turn metro on/off (would be nice to have custom .wav for that) and chat, and rare occasion mute someone.

I actually would like to help add the MIDI timing output feature, it's been a while but I've done a fair amount of Windows programming over a couple decades. I'll check out the compiler and see what I may be getting myself into.

I think it's going to be hard to compete with ReaNINJAM (I realize that wasn't the mentioned intent) unless some dramatic features are included, although not sure what that would be. But here's some suggestions from a few years of use:
- Large metronome flashing display so drummers in particular don't have to listen to irritating metro or stare at tiny incrementing % interval complete bar
- Hyperlink click functionality in chat, or at least copy/paste. Don't think there's enough people using this to worry much about bad website links.
- Eliminate transmit level slider, messes everyone up when balancing audio in vs out. Probably largest contributor to this problem.
- Create compact view mode so that we can maximize use of the computer display for the DAW. Maybe a narrow vertical slice.
- Make a version that's compatible with VST so that nearly any DAW can be used!
- Make real-time audio transfers to/from server more robust. Too many dropouts seem to occur.
- Sure I'll think of something else...
Hooserdaddy is offline   Reply With Quote
Old 09-16-2012, 10:38 PM   #31
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Quote:
Originally Posted by Hooserdaddy View Post
Wow quick response! I'll actually have to try your version and get back to you on features, just noting what I see on the ReaNINJAM screen vs. what I've seen in your snapshots, maybe there's more than what meets the eye. I really just turn metro on/off (would be nice to have custom .wav for that) and chat, and rare occasion mute someone.
Great, patches are welcome. You may want to join the mailing list at http://groups.google.com/group/wahjam.

There is also an IRC channel at #wahjam IRC on irc.oftc.net if you want to discuss things or need help compiling.

To compile you need a C++ toolchain, the Qt SDK (http://qt.nokia.com/downloads/), PortAudio (http://www.portaudio.com/download.html), and Ogg Vorbis (http://xiph.org/downloads/).

Quote:
Originally Posted by Hooserdaddy View Post
I actually would like to help add the MIDI timing output feature, it's been a while but I've done a fair amount of Windows programming over a couple decades. I'll check out the compiler and see what I may be getting myself into.
MIDI sync can probably be implemented using PortMIDI:
http://sourceforge.net/apps/trac/por.../wiki/portmidi

This MIDI library is supported on Windows, Mac, and Linux. The library interface is described here:
http://sourceforge.net/apps/trac/por...mon/portmidi.h

Quote:
Originally Posted by Hooserdaddy View Post
I think it's going to be hard to compete with ReaNINJAM (I realize that wasn't the mentioned intent) unless some dramatic features are included, although not sure what that would be. But here's some suggestions from a few years of use:
The target audience that I'm going for are non-technical users who are not necessarily familiar with pro audio. I'm focussing on the non-DAW use case - for many people setting up REAPER or another DAW to work with ReaNINJAM is a real hurdle. A stand-alone app that let's them plug in their instrument and jam works better for them.

In that sense it doesn't compete with ReaNINJAM. There is no ASIO or routing support. There's no VST support.

If you want to improve DAW integration that's great. Patches are always welcome.

Quote:
Originally Posted by Hooserdaddy View Post
- Large metronome flashing display so drummers in particular don't have to listen to irritating metro or stare at tiny incrementing % interval complete bar
Good idea. The metronome is unchanged from the official NINJAM client and has a lot of room for improvement ;-).

Quote:
Originally Posted by Hooserdaddy View Post
- Hyperlink click functionality in chat, or at least copy/paste. Don't think there's enough people using this to worry much about bad website links.
This is implemented. There's also a handy voting "+1" feature so you can join a vote with a single click (instead of having to type !vote commands into the chat).

Quote:
Originally Posted by Hooserdaddy View Post
- Eliminate transmit level slider, messes everyone up when balancing audio in vs out. Probably largest contributor to this problem.
There are currently no mixer controls. You can mute remote channels. You can toggle software monitoring and local channel broadcast (xmit). That's it.

The idea behind the cut-down volume controls is to encourage people to set reasonable local volumes. This saves everyone else from having to mix remote channels. In practice I think we'll end up adding a mixer for remote channels since it's sometimes not possible to get people to adjust their volume.

Quote:
Originally Posted by Hooserdaddy View Post
- Create compact view mode so that we can maximize use of the computer display for the DAW. Maybe a narrow vertical slice.
Nice idea.

Quote:
Originally Posted by Hooserdaddy View Post
- Make a version that's compatible with VST so that nearly any DAW can be used!
My current plan is to add VST host support. This would allow VSTi and VST plugins to run inside Wahjam. I believe it will be easier to support non-technical users with VST plugins inside Wahjam than dealing with the complexities of their DAW and routing everything into Wahjam correctly.

If they get stuck trying to set up a DAW, I can't help them. Whereas if there is a problem loading a plugin, it's something I can debug and hopefully fix.

Quote:
Originally Posted by Hooserdaddy View Post
- Make real-time audio transfers to/from server more robust. Too many dropouts seem to occur.
- Sure I'll think of something else...
Regarding dropouts, I haven't investigated but have also experienced them from time to time. It would be handy to at least display an indication that there's a network issue. Lacking any cue from the client, the dropouts make me wonder if there is a bug .
stefanha is offline   Reply With Quote
Old 09-17-2012, 05:04 AM   #32
Veto
Human being with feelings
 
Join Date: Aug 2010
Posts: 694
Default

Cool you guys have started this project, i'm reading this thread with exitement.

I dont have much to contribute, all ideas of mine were already proposed.
I'd like to especially support Hooserdaddy's request for midisync for Wahjam, that would just be great.
Veto is offline   Reply With Quote
Old 09-17-2012, 09:46 PM   #33
Hooserdaddy
Human being with feelings
 
Join Date: Nov 2010
Posts: 4
Default

Is there a way to ask build questions without filling up this thread? I looked at the IRC and it didn't seem to be available, and the google group and was full of automated messages. At the moment was wondering if you had the .pro Qt project files for ogg vorbis and port audio handy. Worth checking in.

Another feature that would help me alot is a way to tie midi or some control to the xmit button, so we can noodle w/o sending, then when we're ready to send you don't have to drop the guitar etc just stomp a midi pedal etc and away you go.

Last edited by Hooserdaddy; 09-21-2012 at 09:15 PM.
Hooserdaddy is offline   Reply With Quote
Old 06-10-2013, 12:07 PM   #34
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

First, sorry for the late reply. I have not been monitoring this forum.

Quote:
Is there a way to ask build questions without filling up this thread? I looked at the IRC and it didn't seem to be available, and the google group and was full of automated messages.
If you email the mailing list I'll see the mail:
https://groups.google.com/forum/?fro...#!forum/wahjam

I am always logged in to #wahjam on irc.oftc.net. Feel free to ping me any time.

Quote:
At the moment was wondering if you had the .pro Qt project files for ogg vorbis and port audio handy. Worth checking in.
I recommend using the nightly build:
https://github.com/wahjam/wahjam/wiki

On Windows the nightly builds has all dependencies included, you don't need to build anything.

On Linux the nightly build depends on your distros libogg, libvorbis, portaudio, and Qt packages. They should be easy to install using the package manager.

Wahjam uses pkg-config when building from source. If you want to build from source on Windows then I recommend using mingw-get to set up a mingw build environment with pkg-config:
http://sourceforge.net/projects/ming...ler/mingw-get/

You can install stuff in mingw and the Wahjam build will find libogg, libvorbis, and portaudio using pkg-config.

Quote:
Another feature that would help me alot is a way to tie midi or some control to the xmit button, so we can noodle w/o sending, then when we're ready to send you don't have to drop the guitar etc just stomp a midi pedal etc and away you go.
Yes, I agree. That would be fantastic and MIDI support is on my roadmap, both to control Wahjam itself and also to send to VSTi plugins (like samplers or synthesizers).
stefanha is offline   Reply With Quote
Old 06-10-2013, 11:35 PM   #35
smasha
Human being with feelings
 
Join Date: Aug 2006
Posts: 286
Default

Doesn't ninjam support playing of vstis through midi?

Explains why I can't get it to work.
smasha is offline   Reply With Quote
Old 06-10-2013, 11:49 PM   #36
stefanha
Human being with feelings
 
Join Date: Nov 2011
Posts: 18
Default

Quote:
Doesn't ninjam support playing of vstis through midi?
The official stand-alone NINJAM client does not support VST or VSTi. You need to use REAPER if you want to use VST/VSTi plugins.

In Wahjam, the fork of the official stand-alone NINJAM client that I develop, VST support was added a few months ago. MIDI and VSTi are not yet supported.
stefanha is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 01:48 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.